<div dir="ltr">> a probe of smtpd will look not much different from the many things out there on the internet already maliciously probing smtpd trying to find open relays.<div><br></div><div>It would look very different though, there's a large difference between trying to probe for an open relay and just making a connection without any specific commands being issued.</div><div><br></div><div>> because common configurations of fail2ban used with postfix and others absolutely will ban your IP at the host operating system level (iptables or other) after multiple connection attempts and no successful mail transfer or authentication.</div><div><br></div><div>If a few connections are sufficient to trigger that, then such configurations are simply too trigger-happy. Checking the existence and availability of a domain's MX is a very common operation. Things like rspamd have such functionality built-in and I'm sure there are many others.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 20, 2022 at 8:23 PM Eric Kuhnke <<a href="mailto:eric.kuhnke@gmail.com">eric.kuhnke@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I would discourage anyone from relying upon the data from "probing" the MX and SMTP daemons for a domain name no matter what port they run on, because common configurations of fail2ban used with postfix and others absolutely will ban your IP at the host operating system level (iptables or other) after multiple connection attempts and no successful mail transfer or authentication. <br></div><div><br></div><div>a probe of smtpd will look not much different from the many things out there on the internet already maliciously probing smtpd trying to find open relays.</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 20 Sept 2022 at 09:22, Simon Brandt via ripe-atlas <<a href="mailto:ripe-atlas@ripe.net" target="_blank">ripe-atlas@ripe.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <div>Hi Michel,<br>
      <br>
      Currently, HTTP and SSL are separate measurements. But for SMTP it
      will probably not work this way... Encryption is not mandatory for
      SMTP and thus negotiated between client and server every time on
      port 25. Ports 465 and 587 are used for Client Email Submission.
      You could run some measurements for these ports as well, but for
      the beginning, i would focus on server2server communication.<br>
      <br>
      So here's what i think:<br>
      <br>
      What we could measure:<br>
      - General reachability/availability of the e-mail service<br>
      - Response time of the remote server: time between connection
      establish and first SMTP response (220 service ready)<br>
      - Which enhanced status codes are offered by the server?<br>
      - Forward/Reverse DNS matching?<br>
      - SMTP banner matching the DNS name?<br>
          - if not: what is it?<br>
      - Does the remote server offer encryption (250-STARTTLS)<br>
      - Which cipher settings are offered by the server (SSL/TLS
      Version, Key Exchange Algorithms, Encryption Algorithms, Hashing
      Algorithms)<br>
          - alternatively: Which cipher setting has been negotiated
      between probe and server?<br>
      - Can we successfully establish a TLS connection?<br>
      - Certificate Check: is the server-certificate valid and does it
      match the hostname?<br>
      - Forced Encryption: MTA-STS available and 'enforced' or 'testing'
      or 'report'?<br>
      - Forced Authentication: DANE available and check successfull?<br>
      <br>
      <br>
      What we should not do:<br>
      - send MAIL FROM: command<br>
      - send RCPT TO: command<br>
      - send DATA command<br>
      - measure e-mail delivery/roundtrip time, etc.<br>
      - Sending e-mails at all<br>
      <br>
      The Atlas probe should quit the connection after the data is
      collected. An actual e-mail should not be send. The target
      mailserver would count this session as "incomplete" or "aborted"
      which is totally fine. If someone would want to monitor what
      happens after a mailserver has successfully accepted a testmail,
      he should better use a monitoring service/solution. We measure the
      INTERnet, not what comes after (Intra) :)<br>
      <br>
      I don't expect any "spam" problems. Since the Atlas probes
      wouldn't send e-mails, there's nothing a spamfilter could analyze.
      The only thing that could theoretically happen, is that the probes
      ip addresses are flagged as bad by services like Spamhaus etc. and
      thus be listed on DNSBL/IPBL, but i really don't see a reason why
      that should happen. There wouldn't be any activity originating
      from the probes which could be classified as bad. IP addresses are
      normally only blacklisted, if they send unwanted mails like spam.
      Also: there are a lot of "check you mailserver" or "check your
      SSL/TLS" websites. The RIPE Atlas probes would behave the same
      way. No big deal.<br>
      <br>
      Maybe we can think of an "extended" SMTP measurement where RIPE
      Atlas sends actual e-mails, but that would require (in my
      opinion), that the person who is creating the measurement somehow
      provides proof, to be the owner of the target mailserver.<br>
      <br>
      <br>
      BR,<br>
      Simon<br>
      <br>
      <br>
      On 15.09.22 12:03, Michel Stam wrote:<br>
    </div>
    <blockquote type="cite">
      
      Hello Simon,
      <div><br>
      </div>
      <div>Thank you for the suggestion.</div>
      <div><br>
      </div>
      <div>I have a couple of questions to get a better idea:</div>
      <div>
        <ul>
          <li>Can you maybe describe what a SMTP measurement
            would look like?</li>
          <ul>
            <li>Simple EHLO/HELO</li>
            <li>Sending an email to a designated address (which
              would then validate that the SMTP server is capable of
              relaying etc.)</li>
          </ul>
          <li>How would DNSBL or other spam prevention
            techniques fit into this? </li>
          <li>What would the result be? </li>
          <ul>
            <li>Delay until mail received</li>
            <li>Response time by the actual mail server</li>
            <li>Using the Received: headers to get a
              “traceroute” like result.</li>
          </ul>
          <li>What about the more uncommon ports such as 565
            (SMTP+SSL/TLS) or 587 (mail submission port).</li>
          <li>How can we prevent this implementation from
            having RIPE Atlas be identified as a spam bot network?</li>
        </ul>
      </div>
      <div>
        <div> </div>
        <div>Best regards,</div>
        <div><br>
        </div>
        <div>Michel</div>
        <div><br>
          <blockquote type="cite">
            <div>On 3 Sep 2022, at 14:48, Simon Brandt via
              ripe-atlas <<a href="mailto:ripe-atlas@ripe.net" target="_blank">ripe-atlas@ripe.net</a>>
              wrote:</div>
            <br>
            <div>
              
              <div> Hello,<br>
                <br>
                i'd like to start a discussion about having a RIPE Atlas
                SMTP measurements.<br>
                First of all: yes, i know there's a big obstacle for
                such a measurement type. A lot of probes are deployed
                using enduser internet-connections like dsl, cable, etc.
                with dynamic/eyeball IP addresses. Those IP spaces are
                usually blocked by SMTP servers as approach to reduce
                spam mails. For Example: by using blocklists like
                Spamhaus PBL. So a proper SMTP measurement wouldn't
                work.<br>
                <br>
                BUT we could have an easy way for RIPE Atlas probe
                hosters to signalize, that their probe is eligible for
                SMTP measurements:<br>
                <br>
                Step 1: enable "Simple DNS Entry"<br>
                Step 2: create a matching reverse DNS record for the
                probes IP address<br>
                <br>
                Everybody who is able so configure a reverse DNS record
                for his probes IP address, is most likely using a
                non-dynamic/non-home ip address space e.g. a datacenter
                or office network. If an ISP provides the option for his
                customers to configure a reverse DNS record, it's most
                likely a "business-customer" subnet which can be used to
                run mailservers. After Step 1+2 are done, the RIPE Atlas
                platform would easily be able to verify if
                forward-confirmed reverse DNS is successful, and if so,
                automatically enable that probe for SMTP measurements.
                Alternatively: probe hosters choose their own
                Forward-confirmed reverse DNS name and submit it on the
                RIPE Atlas website.<br>
                <br>
                Also: if we would have STMP measurements,
                forward-confirmed reverse DNS should be mandatory for
                anchors, or is it already?<br>
                <br>
                Why should we have SMTP measurements?<br>
                <br>
                Besides general reachability checks, we could also
                evaluate SMTP response codes. But the most important
                thing for me is this: the SMTP protocol is old. Very
                old. From a security point of view, it's absolutely
                outdated. Most security features have been added years
                after the initial RfC. Thus, those security features are
                optional. Mandatory SMTP encryption is not provided by
                the SMTP RfC. So both sides have to signalize, that they
                are capable of encryption using the STARTTLS command. An
                attacker (man-in-the-middle) can perform a downgrade
                attack by suppressing the STARTTLS command. So both
                sides are forced to fallback and communicate
                unencrypted. RIPE Atlas would be a really good tool to
                identify such attacks, by monitor/measure the (enhanced)
                status codes of a target.<br>
                <br>
                But there's more!<br>
                I see a two-sided model here. Either use the RIPE Atlas
                SMTP measurements to monitor/measure your own mailserver
                by alot of other RIPE probes out there, OR probe hosters
                could run SMTP measurements originating from their own
                probe to find out, if their own IP address is currently
                blocked by other mailservers.<br>
                <br>
                <br>
                What do you think?<br>
                <br>
                <br>
                BR,<br>
                Simon<br>
              </div>
              -- <br>
              ripe-atlas mailing list<br>
              <a href="mailto:ripe-atlas@ripe.net" target="_blank">ripe-atlas@ripe.net</a><br>
              <a href="https://mailman.ripe.net/" target="_blank">https://mailman.ripe.net/</a><br>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </div>

-- <br>
ripe-atlas mailing list<br>
<a href="mailto:ripe-atlas@ripe.net" target="_blank">ripe-atlas@ripe.net</a><br>
<a href="https://mailman.ripe.net/" rel="noreferrer" target="_blank">https://mailman.ripe.net/</a><br>
</blockquote></div>
-- <br>
ripe-atlas mailing list<br>
<a href="mailto:ripe-atlas@ripe.net" target="_blank">ripe-atlas@ripe.net</a><br>
<a href="https://mailman.ripe.net/" rel="noreferrer" target="_blank">https://mailman.ripe.net/</a><br>
</blockquote></div>