<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://lists.ripe.net/mailman/listinfo/ripe-atlas"
target="_blank" rel="noreferrer"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.ripe.net/mailman/listinfo/ripe-atlas</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://lists.ripe.net/mailman/listinfo/ripe-atlas"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.ripe.net/mailman/listinfo/ripe-atlas</a><br>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>