<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">There's literally no danger for you
      (recipient), if the sender terminates the connection before the an
      e-mail has been successfully transmitted. No need to ban the ip
      address. You would only risk to block a legitimate ip address
      which might have trouble sending e-mails to you. If you want to do
      this because you don't want to see such connections in you logs
      that's fine. But i do not share your opinion, that this is a
      common configuration.<br>
      <br>
      However, we have digressed from the topic.<br>
      <br>
      BR,<br>
      Simon<br>
      <br>
      <br>
      <br>
      On 20.09.22 21:47, Eric Kuhnke wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAB69EHhTHq0uWpLX=RS0zOKmqv3zfCP3qUCYde09VXLMOCmokA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="auto">No legitimate incoming SMTP traffic comes from IPs
        that abort connections to my mx prior to attempting to deliver
        mail, so however I choose to declutter my log files has
        absolutely zero real world impact in deliverablity of legitimate
        incoming mail. Nor does it hurt anybody at the other end
        whatever the connect-and-do-nothing software at the other side. </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Tue, Sep 20, 2022, 12:37 PM
          <<a href="mailto:ripe.net@toppas.net"
            moz-do-not-send="true" class="moz-txt-link-freetext">ripe.net@toppas.net</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div>
            <div>>> 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">
              <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"
                    rel="noreferrer" 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" rel="noreferrer"
                                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" rel="noreferrer"
                                moz-do-not-send="true"
                                class="moz-txt-link-freetext">ripe-atlas@ripe.net</a><br>
                              <a
                                href="https://mailman.ripe.net/"
                                target="_blank" rel="noreferrer"
                                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"
                    rel="noreferrer" moz-do-not-send="true"
                    class="moz-txt-link-freetext">ripe-atlas@ripe.net</a><br>
                  <a
                    href="https://mailman.ripe.net/"
                    rel="noreferrer noreferrer" target="_blank"
                    moz-do-not-send="true" class="moz-txt-link-freetext">https://mailman.ripe.net/</a><br>
                </blockquote>
              </div>
            </blockquote>
            <br>
          </div>
        </blockquote>
      </div>
    </blockquote>
    <br>
  </body>
</html>