<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" 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="">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="">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/">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></body></html>