<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Hi Michael,<br>
      <br>
      <blockquote type="cite">Both netcat and openssl wait for the 220
        to continue. If a timeout would occur during the STARTTLS phase,
        or before the 220, would this differ from a conclusion
        perspective? In other words, is it necessary to test once for
        the 220 to appear (or a timeout), then another time to see if
        the STARTTLS completes?</blockquote>
      <br>
      If you have a timeout while waiting for the initial 220 response
      (service ready), the service is not available. Maybe the SMTP
      daemon is not running or not answering for some reason, or there's
      a network issue. If a timeout occurs later during the STARTTLS
      phase, the server is available and also the underlying network
      connection seems to be fine. So yes, the conclusion would be a
      different. But we still don't have to run two separate tests, i
      think.<br>
      <br>
      <blockquote type="cite">Could this be folded into a single test
        that does a 220, then the STARTTLS and will report error when
        there’s a fail in the process?</blockquote>
      <br>
      Yes. Since we do not really want to send an e-mail, we can
      probably use OpenSSL for everything in a single run. If you use
      the -debug parameter, you'll get *very* detailed output which
      contains all informations we want (except for response-times, i
      think). There might be a more elegant way to get a better-looking
      output from OpenSSL. But I don't know how, to be honest. I haven't
      read the whole man-page :)<br>
      <br>
      <blockquote type="cite">$ openssl s_client -starttls smtp -connect
        mahimahi.ripe.net:25 -debug</blockquote>
      <br>
      Most work is probably to study the OpenSSL documentation, to find
      out the different error messages we have to expect, depending on
      the problems we might face:<br>
      <br>
      - TCP handshake not successfull<br>
      - Server does not reply with 220 (timeout)<br>
      - Server does not reply with 220 (server replies with another 4xx
      or 5xx code)<br>
      - Server is not ESMTP capable**<br>
      - Connection successfull, but the server does not offer
      250-STARTTLS (not supported or suppressed because of MITM attack)<br>
      - 250-STARTTLS was offered, but establishing encryption was still
      not successful for some reason<br>
      <br>
      and maybe other typical certificate problems like:<br>
      <br>
      - certificate invalid (self-signed)<br>
      - certificate invalid (expired)<br>
      - certificate invalid (broken chain)<br>
      <br>
      <br>
      **<br>
      SMTP Encryption is optional, but it is not supported by the
      original SMTP protocoll (RFC 821). To use STARTTLS, the mailserver
      has to support SMTP "Service Extensions" aka. ESMTP. ESMTP has
      been introduced 13 years later by RFC 1869. From a communication
      perspective, the main difference is, that the initiator of the
      SMTP connection (client) is using EHLO instead of HELO (EHLO =
      Enhanced HELO). If the server does support ESMTP, it will tell the
      client it's features. If the server does not support ESMTP, it
      will reply with an error. I don't know what the OpenSSL output
      looks like, if you try to connect to a server which does not
      support ESMTP. It will probably output some error message. This
      error should be evaluated by the Atlas SMTP measurement too. 99.9%
      of all mailservers nowadays should support ESMTP, but there might
      be some usecases... "special application blabla". It could be
      possible that someone would start a Atlas SMTP measurement for a
      non-ESMTP compliant target. That's why i am mention this.<br>
      <br>
      <br>
      BR,<br>
      Simon<br>
      <br>
      <br>
      <br>
      On 05.10.22 17:55, Michel Stam wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:4C7C12CC-241C-400B-AF82-D6F663379970@ripe.net">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      Hi Simon,
      <div class=""><br class="">
      </div>
      <div class="">Thanks for the rundown, that helps.</div>
      <div class=""><br class="">
      </div>
      <div class="">The Atlas measurement code uses something different
        than nc, but that isn’t really relevant, the process is roughly
        the same.</div>
      <div class=""><br class="">
      </div>
      <div class="">
        <div class="">I have a question, though. Both netcat and openssl
          wait for the 220 to continue. If a timeout would occur during
          the STARTTLS phase, or before the 220, would this differ from
          a conclusion perspective? In other words, is it necessary to
          test once for the 220 to appear (or a timeout), then another
          time to see if the STARTTLS completes? Could this be folded
          into a single test that does a 220, then the STARTTLS and will
          report error when there’s a fail in the process?</div>
      </div>
      <div class=""><br class="">
      </div>
      <div class="">As to the TCP traceroute, this is something used by
        people to measure service availability using Atlas. It isn’t
        something I came up with perse, but yes its to measure response
        time as well as availability of the service at the TCP level.</div>
      <div class=""><br class="">
      </div>
      <div class="">With regard to additional check such as DANE, these
        lie somewhere between DNSSEC and TLS measurement. I’ll make a
        note of this, thanks for the suggestion.</div>
      <div class=""><br class="">
      </div>
      <div class="">As to measurements in general, all currently support
        IPv6 to my knowledge. I agree that new ones should support this
        too.</div>
      <div class=""><br class="">
      </div>
      <div class="">Regards,</div>
      <div class=""><br class="">
      </div>
      <div class="">Michel</div>
      <div class=""><br class="">
      </div>
      <div class=""><br class="">
      </div>
      <div class="">
        <div>
          <blockquote type="cite" class="">
            <div class="">On 1 Oct 2022, at 17:11, <a
                href="mailto:ripe.net@toppas.net"
                class="moz-txt-link-freetext" moz-do-not-send="true">ripe.net@toppas.net</a>
              wrote:</div>
            <br class="Apple-interchange-newline">
            <div class="">
              <meta http-equiv="Content-Type" content="text/html;
                charset=UTF-8" class="">
              <div class="">
                <div class="moz-cite-prefix">Hi Michel,<br class="">
                  <br class="">
                  <blockquote type="cite" class="">That would would
                    indeed mean a combination of TCP and SSL measurement
                    to achieve all 3 required functions. Is it
                    problematic if the result comes from multiple steps?
                    If so, can you explain how?</blockquote>
                  <blockquote type="cite" class="">
                    <div class="">The intent of the measurement would be
                      to validate whether an SMTP server is:</div>
                    <ul class="MailOutline">
                      <li class="">reachable</li>
                      <li class="">responsive</li>
                      <li class="">capable of secured transmissions</li>
                    </ul>
                  </blockquote>
                  <br class="">
                  First, let's define the testmethod. In my opinion:<br
                    class="">
                  <br class="">
                  - reachable<br class="">
                  3-way TCP Handshake with target on tcp/25 successful?<br
                    class="">
                  <br class="">
                  - responsive<br class="">
                  when establishing and SMTP connection, does the
                  smtp-server signalize readiness of the service (SMTP
                  220)?<br class="">
                  <br class="">
                  - capable of secured transmissions<br class="">
                  when sending an EHLO, the server will tell us his
                  features. 250-STARTTLS should be there.<br class="">
                  <br class="">
                  <br class="">
                  For all three checks, it's the easiest to use netcat.<br
                    class="">
                  <br class="">
                  Reachability:<br class="">
                  <blockquote type="cite" class="">$ nc -vz <a
                      href="http://mahimahi.ripe.net" class=""
                      moz-do-not-send="true">mahimahi.ripe.net</a> 25<br
                      class="">
                    <a href="http://mahimahi.ripe.net" class=""
                      moz-do-not-send="true">mahimahi.ripe.net</a>
                    [193.0.19.114] 25 (smtp) open</blockquote>
                  <br class="">
                  Note, that we have not measured the response time.
                  That's why you wanted to use TCP Traceroute, right? We
                  can also go with TCP Traceroute here.<br class="">
                  <br class="">
                  <br class="">
                  Responsiveness (wait for 220):<br class="">
                  <blockquote type="cite" class="">$ nc -C <a
                      href="http://mahimahi.ripe.net" class=""
                      moz-do-not-send="true">mahimahi.ripe.net</a> 25<br
                      class="">
                    220 <a href="http://mahimahi.ripe.net" class=""
                      moz-do-not-send="true">mahimahi.ripe.net</a> ESMTP
                    Sat, 01 Oct 2022 15:25:22 +0200<br class="">
                    quit<br class="">
                    221 <a href="http://mahimahi.ripe.net" class=""
                      moz-do-not-send="true">mahimahi.ripe.net</a>
                    closing connection<br class="">
                  </blockquote>
                  <br class="">
                  You might want to use the -w option here, to specify a
                  timeout.<br class="">
                  <br class="">
                  <br class="">
                  capable of secured transmissions (send EHLO and check
                  response):<br class="">
                  <blockquote type="cite" class="">$ nc -C <a
                      href="http://mahimahi.ripe.net" class=""
                      moz-do-not-send="true">mahimahi.ripe.net</a> 25<br
                      class="">
                    220 <a href="http://mahimahi.ripe.net" class=""
                      moz-do-not-send="true">mahimahi.ripe.net</a> ESMTP
                    Sat, 01 Oct 2022 15:54:04 +0200<br class="">
                    EHLO <a href="http://p123456.probes.atlas.ripe.net"
                      class="" moz-do-not-send="true">p123456.probes.atlas.ripe.net</a><br
                      class="">
                    <a href="http://250-mahimahi.ripe.net" class=""
                      moz-do-not-send="true">250-mahimahi.ripe.net</a>
                    Hello <a
                      href="http://p123456.probes.atlas.ripe.net"
                      class="" moz-do-not-send="true">p123456.probes.atlas.ripe.net</a>
                    [123.123.123.123]<br class="">
                    250-SIZE 52428800<br class="">
                    250-8BITMIME<br class="">
                    250-ETRN<br class="">
                    250-PIPELINING<br class="">
                    250-PIPE_CONNECT<br class="">
                    250-STARTTLS<br class="">
                    250 HELP</blockquote>
                  <br class="">
                  <br class="">
                  To check the Certificate validity and if encryption is
                  indeed successful, we can use OpenSSL:<br class="">
                  <blockquote type="cite" class="">$ openssl s_client
                    -starttls smtp -connect <a
                      href="http://mahimahi.ripe.net:25" class=""
                      moz-do-not-send="true">mahimahi.ripe.net:25</a><br
                      class="">
                  </blockquote>
                  (output to long, i stripped it)<br class="">
                  <br class="">
                  <br class="">
                  <br class="">
                  <blockquote type="cite" class="">You’re correct, the
                    current SSL measurement does not support any form of
                    STARTTLS, this is something that would have to be
                    considered for implementation. I assume, much like
                    with SMTP, similar cases could be made for
                    IMAP4/POP3 or XMPP.</blockquote>
                  Yeah, as far as i know, STARTTLS is also used for
                  imap, pop3, xmpp and ftp (ftps, not sftp).<br class="">
                  <br class="">
                  <br class="">
                  As i said before, there are additional e-mail security
                  features that we could check. There's MTA-STS, where
                  we would have to perform a combination of HTTP and SSL
                  check. Also, there is DANE, where we would perform a
                  combination of DNS and SSL check (including DNSSEC).
                  But DANE can be used for other protocols as well, not
                  only SMTP. DNSSEC/DANE are perhaps worth a separate
                  check type.<br class="">
                  <br class="">
                  Last but no least, we should check for
                  Forward-confirmed reverse DNS and matching SMTP
                  banner, which is a combination of DNS and netcat
                  check. This would be a reasonable part of every smtp
                  measurement.<br class="">
                  <br class="">
                  <br class="">
                  Please note, that the creator of the measurement
                  should either specify the exact mailserver FQDN, or
                  the target Domain. In the latter case, an MX record
                  lookup has to be performed before the measurement
                  starts, not while the measurement is running.
                  Otherwise it could cause credit consumption trouble,
                  if suddenly multiple mx records are added the domain,
                  while the measurement is running.<br class="">
                  <br class="">
                  Oh, and please make the SMTP measurement IPv6 capable
                  :)<br class="">
                  <br class="">
                  <br class="">
                  BR,<br class="">
                  Simon<br class="">
                  <br class="">
                  <br class="">
                  <br class="">
                  On 29.09.22 11:50, Michel Stam wrote:<br class="">
                </div>
                <blockquote type="cite"
                  cite="mid:2D29819A-6B48-44F8-A15A-2F04B2912F29@ripe.net"
                  class="">
                  <meta http-equiv="Content-Type" content="text/html;
                    charset=UTF-8" class="">
                  Hi Simon,
                  <div class=""><br class="">
                  </div>
                  <div class="">
                    <blockquote type="cite" class="">
                      <div class="">
                        <div class="moz-cite-prefix">>Can we achieve
                          the first 2 items of this measurement by doing
                          a TCP traceroute on port 25?<br class="">
                          I would say no. Using TCP Traceroute, you can
                          may check for reachability/responsiveness of
                          the host, but not the actual service (smtp).<br
                            class="">
                        </div>
                      </div>
                    </blockquote>
                    <div class=""><br class="">
                    </div>
                    <div class="">That would would indeed mean a
                      combination of TCP and SSL measurement to achieve
                      all 3 required functions. Is it problematic if the
                      result comes from multiple steps? If so, can you
                      explain how?</div>
                    <div class=""><br class="">
                    </div>
                    <div class="">I just noticed that the SSL
                      measurement offers a time to connect, response
                      time, certificates as well as SSL alerts which may
                      be leveraged, see here: <a
                        href="https://atlas.ripe.net/docs/apis/result-format/#version-4610"
                        class="moz-txt-link-freetext"
                        moz-do-not-send="true">https://atlas.ripe.net/docs/apis/result-format/#version-4610</a>,
                      under "Version 4610 TLS (SSL) GET Cert”. TCP
                      traceroute may not be necessary in this case,
                      although I understand it is typically used to
                      determine service availability.</div>
                    <br class="">
                    <blockquote type="cite" class="">
                      <div class="">
                        <div class="moz-cite-prefix">>Does the SSL
                          measurement cover the intended use cases?<br
                            class="">
                          I would say no. Correct me if am am wrong.
                          Usually (for example HTTPS or LDAPS) the
                          SSL/TLS encryption starts right after the TCP
                          3-way Handshake was successfull. For SMTP,
                          that doesn't work. That's because regular SMTP
                          communication starts first, so both sides can
                          negotiate if SSL/TLS encryption is possible
                          (via Enhanced SMTP Status Codes). However, as
                          far as i know, OpenSSL <u class="">does</u> support
                          SMTP and STARTTLS. So you could probably
                          modify the existing SSL measurement.<br
                            class="">
                          <br class="">
                          Keep in mind that there's also MTA-STS and
                          DANE, which are really enhancing SMTPs
                          security. A dedicated SMTP measurement would
                          be a good thing.<br class="">
                        </div>
                      </div>
                    </blockquote>
                  </div>
                  <div class=""><br class="">
                    <div class="">You’re correct, the current SSL
                      measurement does not support any form of STARTTLS,
                      this is something that would have to be considered
                      for implementation. I assume, much like with SMTP,
                      similar cases could be made for IMAP4/POP3 or
                      XMPP.</div>
                    <div class="">I would like to understand if there
                      are particulars you are looking for that need to
                      be considered outside of STARTTLS support?</div>
                    <div class=""><br class="">
                    </div>
                    <div class="">Regards,</div>
                    <div class=""><br class="">
                    </div>
                    <div class="">Michel</div>
                    <div class=""><br class="">
                    </div>
                    <div class=""><br class="">
                    </div>
                    <div class="">
                      <blockquote type="cite" class="">
                        <div class="">On 23 Sep 2022, at 17:08, <a
                            href="mailto:ripe.net@toppas.net"
                            class="moz-txt-link-freetext"
                            moz-do-not-send="true">ripe.net@toppas.net</a>
                          wrote:</div>
                        <br class="Apple-interchange-newline">
                        <div class="">
                          <meta http-equiv="Content-Type"
                            content="text/html; charset=UTF-8" class="">
                          <div class="">
                            <div class="moz-cite-prefix">Hi Michel,<br
                                class="">
                              <br class="">
                              >Are we monitoring the Internet or
                              monitoring a service using the proposed
                              SMTP measurement?<br class="">
                              First of all, we are monitoring the
                              service of a specific target. Same as http
                              or ntp measurements, just another
                              protocol. But we also monitor the
                              Internet. Using an SMTP measurement, we
                              could identify censorship or discover
                              Man-in-the-middle attacks (downgrade
                              attack by suppressing the STARTTLS
                              command).<br class="">
                              <br class="">
                              >Can we achieve the first 2 items of
                              this measurement by doing a TCP traceroute
                              on port 25?<br class="">
                              I would say no. Using TCP Traceroute, you
                              can may check for
                              reachability/responsiveness of the host,
                              but not the actual service (smtp).<br
                                class="">
                              <br class="">
                              >Does the SSL measurement cover the
                              intended use cases?<br class="">
                              I would say no. Correct me if am am wrong.
                              Usually (for example HTTPS or LDAPS) the
                              SSL/TLS encryption starts right after the
                              TCP 3-way Handshake was successfull. For
                              SMTP, that doesn't work. That's because
                              regular SMTP communication starts first,
                              so both sides can negotiate if SSL/TLS
                              encryption is possible (via Enhanced SMTP
                              Status Codes). However, as far as i know,
                              OpenSSL <u class="">does</u> support SMTP
                              and STARTTLS. So you could probably modify
                              the existing SSL measurement.<br class="">
                              <br class="">
                              Keep in mind that there's also MTA-STS and
                              DANE, which are really enhancing SMTPs
                              security. A dedicated SMTP measurement
                              would be a good thing.<br class="">
                              <br class="">
                              BR,<br class="">
                              Simon<br class="">
                              <br class="">
                              <br class="">
                              <br class="">
                              On 23.09.22 16:04, Michel Stam wrote:<br
                                class="">
                            </div>
                            <blockquote type="cite"
                              cite="mid:B5640B9C-ADC1-496C-8145-4D8C48EA8D5D@ripe.net"
                              class="">
                              <meta http-equiv="Content-Type"
                                content="text/html; charset=UTF-8"
                                class="">
                              Hi everyone,
                              <div class=""><br class="">
                              </div>
                              <div class="">Great that this request
                                sparked a good discussion on the merits
                                of a measurement, as well as its
                                potential impact on servers around the
                                world. Good to see this!</div>
                              <div class=""><br class="">
                              </div>
                              <div class="">So I’m going to do a quick
                                recap here, hoping that I capture the
                                intent and the concerns correctly.
                                Please correct me if I err.</div>
                              <div class=""><br class="">
                              </div>
                              <div class="">The intent of the
                                measurement would be to validate whether
                                an SMTP server is:</div>
                              <div class="">
                                <ul class="MailOutline">
                                  <li class="">reachable</li>
                                  <li class="">responsive</li>
                                  <li class="">capable of secured
                                    transmissions</li>
                                </ul>
                                <div class=""><br class="">
                                </div>
                              </div>
                              <div class="">The concern is that such a
                                check would trigger one of a variety of
                                anti spam measures in place around the
                                world, and/or cause undue traffic to
                                SMTP server operators.</div>
                              <div class=""><br class="">
                              </div>
                              <div class="">With this in mind, I am
                                wondering: </div>
                              <div class="">
                                <ul class="MailOutline">
                                  <li class="">Are we monitoring the
                                    Internet or monitoring a service
                                    using the proposed SMTP
                                    measurement? </li>
                                  <li class="">Can we achieve the first
                                    2 items of this measurement by doing
                                    a TCP traceroute on port 25?</li>
                                  <li class="">Does the SSL measurement
                                    cover the intended use cases?</li>
                                  <ul class="">
                                    <li class=""> Is it worth exploring
                                      STARTTLS support as an extension
                                      and what would the implications
                                      be?</li>
                                  </ul>
                                </ul>
                                <div class=""><br class="">
                                </div>
                              </div>
                              <div class="">Have a good weekend!</div>
                              <div class=""><br class="">
                              </div>
                              <div class="">Best regards,</div>
                              <div class=""><br class="">
                              </div>
                              <div class="">Michel</div>
                              <div class="">
                                <div class=""><br class="">
                                  <blockquote type="cite" class="">
                                    <div class="">On 21 Sep 2022, at
                                      00:11, Avamander <<a
                                        href="mailto:avamander@gmail.com"
                                        class="moz-txt-link-freetext"
                                        moz-do-not-send="true">avamander@gmail.com</a>>
                                      wrote:</div>
                                    <br
                                      class="Apple-interchange-newline">
                                    <div class="">
                                      <div dir="ltr" class="">>
                                        Making arguments based upon
                                        extreme cases, assumptions, or
                                        potential-for-collateral-damage
                                        is not scientific. "I know one
                                        that even [...]" Anecdotal 
                                        evidence isn't scientific.
                                        <div class=""><br class="">
                                        </div>
                                        <div class="">From the
                                          perspective of your previous
                                          sentences that's kinda
                                          humorous. "To avoid
                                          unnecessary costs incurred
                                          from disruption of service,
                                          excessive traffic, annoyances
                                          using up *my* time, and
                                          countless other reasonable
                                          rationale from *my* point of
                                          view." Because sure, a few
                                          (hypothetical RIPE probe)
                                          connections are exactly that,
                                          zero exaggeration, right?</div>
                                        <div class=""><br class="">
                                        </div>
                                        <div class="">In the end such
                                          fail2ban-fueled (or similar)
                                          behaviour I initially
                                          addressed, is exactly a
                                          non-scientific extreme-case
                                          assumption-based approach.
                                          There are better and even more
                                          standard ways. </div>
                                        <div class=""><br class="">
                                        </div>
                                        <div class="">Crutch solutions
                                          out in the wild shouldn't be a
                                          showstopper for measuring the
                                          ecosystem. (That is already
                                          quite neglected)</div>
                                        <div class=""><br class="">
                                        </div>
                                        <div class="">> What
                                          _objective_ risk/benefit
                                          analysis are you basing your
                                          opinions upon?<br class="">
                                          <br class="">
                                          And you? What's the
                                          implication here about systems
                                          being as trigger-happy as
                                          previously described?</div>
                                        <div class=""><br class="">
                                        </div>
                                        <div class="">Because sure, at
                                          some point rate limits make
                                          total sense, but certainly not
                                          at the point where it would
                                          ban any potential RIPE probes.</div>
                                        <div class=""><br class="">
                                        </div>
                                        <div class="">>  Are you a
                                          systems administrator?</div>
                                        <div class=""><br class="">
                                        </div>
                                        <div class="">Let's not get into
                                          such measuring contests, even
                                          if it is the RIPE Atlas
                                          mailing list.</div>
                                      </div>
                                      <br class="">
                                      <div class="gmail_quote">
                                        <div dir="ltr"
                                          class="gmail_attr">On Tue, Sep
                                          20, 2022 at 11:42 PM Paul
                                          Theodoropoulos via ripe-atlas
                                          <<a
                                            href="mailto:ripe-atlas@ripe.net"
class="moz-txt-link-freetext" moz-do-not-send="true">ripe-atlas@ripe.net</a>>
                                          wrote:<br class="">
                                        </div>
                                        <blockquote class="gmail_quote"
                                          style="margin:0px 0px 0px
                                          0.8ex;border-left:1px solid
                                          rgb(204,204,204);padding-left:1ex">
                                          <div class=""> On 9/20/2022
                                            10:45 AM, Avamander wrote:<br
                                              class="">
                                            <blockquote type="cite"
                                              class="">
                                              <div dir="ltr" class="">Great
                                                to hear it works for
                                                you, but the potential
                                                unfortunate collateral
                                                from such a blanket
                                                action is not really
                                                RIPE Atlas' problem.
                                                There are more
                                                fine-grained methods
                                                against bruteforce
                                                attempts and open relay
                                                probes, than triggering
                                                on a few connections.</div>
                                            </blockquote>
                                            What _objective_
                                            risk/benefit analysis are
                                            you basing your opinions
                                            upon? Are you a systems
                                            administrator? My
                                            responsibility is to avoid
                                            unnecessary costs incurred
                                            from disruption of service,
                                            excessive traffic,
                                            annoyances using up *my*
                                            time, and countless other
                                            reasonable rationale from
                                            *my* point of view.  <br
                                              class="">
                                            <br class="">
                                            You suggest that it is "not
                                            really RIPE Atlas' problem".
                                            That's very true. And it is
                                            not really my problem if I
                                            bounce yoinky, pointless
                                            probes of my server, and
                                            ruthlessly block them from
                                            contacting my server ever
                                            again. My server, my choice,
                                            my wallet, nobody's business
                                            but my own.<br class="">
                                            <blockquote type="cite"
                                              class="">
                                              <div dir="ltr" class="">
                                                <div class="">Some
                                                  webmasters ban IP's
                                                  for simply visiting a
                                                  domain, I know one
                                                  that even dispatches
                                                  an email to your ISP's
                                                  abuse@ address upon
                                                  visit. Should RIPE
                                                  Atlas probes then not
                                                  probe any HTTP
                                                  servers? The answer is
                                                  obviously no, they
                                                  shouldn't care.</div>
                                              </div>
                                            </blockquote>
                                            Making arguments based upon
                                            extreme cases, assumptions,
                                            or
                                            potential-for-collateral-damage
                                            is not scientific. "I know
                                            one that even [...]"
                                            Anecdotal  evidence isn't
                                            scientific.<br class="">
                                            <br class="">
                                            Note, I run a probe myself.
                                            I don't block any RIPE Atlas
                                            traffic on my separate
                                            servers hosted on AWS,
                                            Oracle, and GCE. <br
                                              class="">
                                            <br class="">
                                            <div class="">-- <br
                                                class="">
                                              Paul Theodoropoulos<br
                                                class="">
                                              <a
                                                href="https://www.anastrophe.com/"
                                                target="_blank" class=""
                                                moz-do-not-send="true">anastrophe.com</a></div>
                                          </div>
                                          -- <br class="">
                                          ripe-atlas mailing list<br
                                            class="">
                                          <a
                                            href="mailto:ripe-atlas@ripe.net"
                                            target="_blank"
                                            class="moz-txt-link-freetext"
                                            moz-do-not-send="true">ripe-atlas@ripe.net</a><br
                                            class="">
                                          <a
                                            href="https://mailman.ripe.net/"
                                            rel="noreferrer"
                                            target="_blank"
                                            class="moz-txt-link-freetext"
                                            moz-do-not-send="true">https://mailman.ripe.net/</a><br
                                            class="">
                                        </blockquote>
                                      </div>
                                      -- <br class="">
                                      ripe-atlas mailing list<br
                                        class="">
                                      <a
                                        href="mailto:ripe-atlas@ripe.net"
                                        class="moz-txt-link-freetext"
                                        moz-do-not-send="true">ripe-atlas@ripe.net</a><br
                                        class="">
                                      <a class="moz-txt-link-freetext"
                                        href="https://mailman.ripe.net/"
                                        moz-do-not-send="true">https://mailman.ripe.net/</a><br
                                        class="">
                                    </div>
                                  </blockquote>
                                </div>
                                <br class="">
                              </div>
                              <br class="">
                              <fieldset
                                class="moz-mime-attachment-header"></fieldset>
                            </blockquote>
                            <br class="">
                          </div>
                        </div>
                      </blockquote>
                    </div>
                    <br class="">
                  </div>
                </blockquote>
                <br class="">
              </div>
            </div>
          </blockquote>
        </div>
        <br class="">
      </div>
    </blockquote>
    <br>
  </body>
</html>