<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Hi Michel,<br>
      <br>
      <blockquote type="cite">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">
        <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>
      First, let's define the testmethod. In my opinion:<br>
      <br>
      - reachable<br>
      3-way TCP Handshake with target on tcp/25 successful?<br>
      <br>
      - responsive<br>
      when establishing and SMTP connection, does the smtp-server
      signalize readiness of the service (SMTP 220)?<br>
      <br>
      - capable of secured transmissions<br>
      when sending an EHLO, the server will tell us his features.
      250-STARTTLS should be there.<br>
      <br>
      <br>
      For all three checks, it's the easiest to use netcat.<br>
      <br>
      Reachability:<br>
      <blockquote type="cite">$ nc -vz mahimahi.ripe.net 25<br>
        mahimahi.ripe.net [193.0.19.114] 25 (smtp) open</blockquote>
      <br>
      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>
      <br>
      <br>
      Responsiveness (wait for 220):<br>
      <blockquote type="cite">$ nc -C mahimahi.ripe.net 25<br>
        220 mahimahi.ripe.net ESMTP Sat, 01 Oct 2022 15:25:22 +0200<br>
        quit<br>
        221 mahimahi.ripe.net closing connection<br>
      </blockquote>
      <br>
      You might want to use the -w option here, to specify a timeout.<br>
      <br>
      <br>
      capable of secured transmissions (send EHLO and check response):<br>
      <blockquote type="cite">$ nc -C mahimahi.ripe.net 25<br>
        220 mahimahi.ripe.net ESMTP Sat, 01 Oct 2022 15:54:04 +0200<br>
        EHLO p123456.probes.atlas.ripe.net<br>
        250-mahimahi.ripe.net Hello p123456.probes.atlas.ripe.net
        [123.123.123.123]<br>
        250-SIZE 52428800<br>
        250-8BITMIME<br>
        250-ETRN<br>
        250-PIPELINING<br>
        250-PIPE_CONNECT<br>
        250-STARTTLS<br>
        250 HELP</blockquote>
      <br>
      <br>
      To check the Certificate validity and if encryption is indeed
      successful, we can use OpenSSL:<br>
      <blockquote type="cite">$ openssl s_client -starttls smtp -connect
        mahimahi.ripe.net:25<br>
      </blockquote>
      (output to long, i stripped it)<br>
      <br>
      <br>
      <br>
      <blockquote type="cite">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>
      <br>
      <br>
      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>
      <br>
      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>
      <br>
      <br>
      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>
      <br>
      Oh, and please make the SMTP measurement IPv6 capable :)<br>
      <br>
      <br>
      BR,<br>
      Simon<br>
      <br>
      <br>
      <br>
      On 29.09.22 11:50, Michel Stam wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:2D29819A-6B48-44F8-A15A-2F04B2912F29@ripe.net">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      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>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>I would like to understand if there are particulars you are
          looking for that need to be considered outside of STARTTLS
          support?</div>
        <div><br class="">
        </div>
        <div>Regards,</div>
        <div><br class="">
        </div>
        <div>Michel</div>
        <div><br class="">
        </div>
        <div><br class="">
        </div>
        <div>
          <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>
  </body>
</html>