<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">>> because common configurations
      of fail2ban [...] absolutely will ban your IP [...] after multiple
      connection attempts and no successful mail transfer<br>
      <br>
      I would consider this a heavy misconfiguration. Please explain to
      me what incomplete SMTP connections have in common with spammers,
      virus/worm/trojan compromised hosts or open relay searching bots.
      Those bad senders WANT to <u>successfully</u> deliver mails to
      you. They will never abort the connection on purpose. For example:
      bots which search for open relays ALWAYS try to send mails with a
      foreign sender and recipient domain. That's how you discover them.
      But as suggested, the Atlas SMTP check should not send E-Mails at
      all, not even send MAIL FROM: or RCPT TO: command.<br>
      <br>
      You will not achieve mitigation of inbound spam/malware/phishing
      traffic by blocking IP addresses of hosts from incomplete SMTP
      sessions. Usually, incomplete SMTP sessions indicate a
      misconfiguration. For example: forced TLS enabled, but expired
      certificate or no matching cipher suites. But that is no reason to
      ban the senders! I think you have to go a little bit deeper in
      your logs and consider why mailtransfer was not successfull,
      before blocking ip addresses.<br>
      <br>
      I am no expert for fail2ban, but as far is i know, i searches for
      failed login attempts. So that affects mostly authenticated SMTP
      connections (client E-Mail submission on tcp/465 or tcp/587),
      right? This should not concern us here.<br>
      <br>
      I work with enterprise mailgateway solutions for years (mostly
      Proofpoint), but i have never encountered what you describe.<br>
      <br>
      Reject or throttle because of too much connections at the same
      time? Yes.<br>
      Reject or throttle because of too much non-existing recipient
      adresses? Yes.<br>
      Reject or throttle because both sender and recipient domain is
      foreign? Yes.<br>
      Reject or throttle because of bad reputation (known spammer or TOR
      exit node ip address)? Yes.<br>
      <br>
      But not because of incomplete SMTP connections. From my point of
      view, I can not confirm that this common behaviour.<br>
      <br>
      BR,<br>
      Simon<br>
      <br>
      <br>
      On 20.09.22 19:22, Eric Kuhnke wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAB69EHgBqegtm1YO-e2fTfrwkExzMYAemBuoubZGNLufSfW5bQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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" moz-do-not-send="true"
            class="moz-txt-link-freetext">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" moz-do-not-send="true"
                        class="moz-txt-link-freetext">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" moz-do-not-send="true"
                        class="moz-txt-link-freetext">ripe-atlas@ripe.net</a><br>
                      <a
                        href="https://mailman.ripe.net/"
                        target="_blank" moz-do-not-send="true"
                        class="moz-txt-link-freetext">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"
            moz-do-not-send="true" class="moz-txt-link-freetext">ripe-atlas@ripe.net</a><br>
          <a href="https://mailman.ripe.net/"
            rel="noreferrer" target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://mailman.ripe.net/</a><br>
        </blockquote>
      </div>
    </blockquote>
    <br>
  </body>
</html>