<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="">This development happened before my joining RIPE NCC, but my guess is that this is historical. Having the OpenSSL library requires more flash and memory, something which the version 1 and 2 probes did not really have.</div><div class=""><div>This doesn’t mean that this needs to be the same going forward, just that adding OpenSSL will take more time, and providing we find a good use for that.</div><div><br class=""></div><div>Cheers,</div><div><br class=""></div><div>Michel</div><div><br class=""><blockquote type="cite" class=""><div class="">On 11 Nov 2022, at 14:16, <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="">
Thanks for your feedback!<br class="">
<br class="">
<blockquote type="cite" class="">Note: the SSL measurement currently does
not use the OpenSSL library.</blockquote>
Is that a reason to not use OpenSSL for SMTP measurements? Are
there any reasons to not use OpenSSL?<br class="">
<br class="">
<br class="">
BR,<br class="">
Simon<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
On 11.11.22 13:57, Michel Stam wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:97E6F025-1C56-427F-97D2-03A05C07B800@ripe.net" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
Hi Simon,
<div class=""><br class="">
</div>
<div class="">This seems to have gotten a bit idle since RIPE85.
Let me give a bit of an update:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">Adding TLSv1.3 is gonna be tricky since the SSL
measurement implements the first stages of the TLS handshake
only. This means adding that complexity to the code, which
as Niall commented to me is not trivial. Note: the SSL
measurement currently does not use the OpenSSL library.</li>
<li class="">Other than retrieving the certificate from the
peer, no other validation happens in the current SSL
measurement. This includes not validating the certificate
chain, which may be a self-signed certificate.</li>
<li class="">Adding STARTTLS the way OpenSSL has done it
involves issuing the appropriate command after receiving
certain output from the remote end, then starting the TLS
handshake. This should be doable.</li>
</ul>
<div class=""><br class="">
</div>
<div class="">Hope this helps, have a nice weekend!</div>
<div class=""><br class="">
</div>
<div class="">Regards,</div>
<div class=""><br class="">
</div>
<div class="">Michel</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div class="">On 20 Oct 2022, at 17:30, Michel Stam <<a href="mailto:mstam@ripe.net" class="moz-txt-link-freetext" moz-do-not-send="true">mstam@ripe.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode:
space; line-break: after-white-space;" class="">Hello
Simon,
<div class=""><br class="">
</div>
<div class="">I’ll first have a look at OpenSSL to gauge
the amount of effort required. I’ll also look at the
existing SSL measurement to see what that offers. That
will likely provide the best path forward. Lastly,
I’ll have an internal discussion on measuring
SMTP/STARTTLS/etc.</div>
<div class=""><br class="">
</div>
<div class="">Ripe 85 is up next week, I’ll be attending
there, so my response may be delayed somewhat.</div>
<div class=""><br class="">
</div>
<div class="">Please bear with me.</div>
<div class=""><br class="">
</div>
<div class="">Regards,</div>
<div class=""><br class="">
</div>
<div class="">Michel</div>
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 16 Oct 2022, at 03:37, <a href="mailto:ripe.net@toppas.net" class="moz-txt-link-freetext" moz-do-not-send="true">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 Michael,<br class="">
<br class="">
<blockquote type="cite" class="">Both netcat
and openssl wait for the 220 to continue.
If a timeout would occur during the
STARTTLS phase, or before the 220, would
this differ from a conclusion perspective?
In other words, is it necessary to test
once for the 220 to appear (or a timeout),
then another time to see if the STARTTLS
completes?</blockquote>
<br class="">
If you have a timeout while waiting for the
initial 220 response (service ready), the
service is not available. Maybe the SMTP
daemon is not running or not answering for
some reason, or there's a network issue. If
a timeout occurs later during the STARTTLS
phase, the server is available and also the
underlying network connection seems to be
fine. So yes, the conclusion would be a
different. But we still don't have to run
two separate tests, i think.<br class="">
<br class="">
<blockquote type="cite" class="">Could this
be folded into a single test that does a
220, then the STARTTLS and will report
error when there’s a fail in the process?</blockquote>
<br class="">
Yes. Since we do not really want to send an
e-mail, we can probably use OpenSSL for
everything in a single run. If you use the
-debug parameter, you'll get *very* detailed
output which contains all informations we
want (except for response-times, i think).
There might be a more elegant way to get a
better-looking output from OpenSSL. But I
don't know how, to be honest. I haven't read
the whole man-page :)<br class="">
<br class="">
<blockquote type="cite" class="">$ openssl
s_client -starttls smtp -connect <a href="http://mahimahi.ripe.net:25/" class="" moz-do-not-send="true">mahimahi.ripe.net:25</a>
-debug</blockquote>
<br class="">
Most work is probably to study the OpenSSL
documentation, to find out the different
error messages we have to expect, depending
on the problems we might face:<br class="">
<br class="">
- TCP handshake not successfull<br class="">
- Server does not reply with 220 (timeout)<br class="">
- Server does not reply with 220 (server
replies with another 4xx or 5xx code)<br class="">
- Server is not ESMTP capable**<br class="">
- Connection successfull, but the server
does not offer 250-STARTTLS (not supported
or suppressed because of MITM attack)<br class="">
- 250-STARTTLS was offered, but establishing
encryption was still not successful for some
reason<br class="">
<br class="">
and maybe other typical certificate problems
like:<br class="">
<br class="">
- certificate invalid (self-signed)<br class="">
- certificate invalid (expired)<br class="">
- certificate invalid (broken chain)<br class="">
<br class="">
<br class="">
**<br class="">
SMTP Encryption is optional, but it is not
supported by the original SMTP protocoll
(RFC 821). To use STARTTLS, the mailserver
has to support SMTP "Service Extensions"
aka. ESMTP. ESMTP has been introduced 13
years later by RFC 1869. From a
communication perspective, the main
difference is, that the initiator of the
SMTP connection (client) is using EHLO
instead of HELO (EHLO = Enhanced HELO). If
the server does support ESMTP, it will tell
the client it's features. If the server does
not support ESMTP, it will reply with an
error. I don't know what the OpenSSL output
looks like, if you try to connect to a
server which does not support ESMTP. It will
probably output some error message. This
error should be evaluated by the Atlas SMTP
measurement too. 99.9% of all mailservers
nowadays should support ESMTP, but there
might be some usecases... "special
application blabla". It could be possible
that someone would start a Atlas SMTP
measurement for a non-ESMTP compliant
target. That's why i am mention this.<br class="">
<br class="">
<br class="">
BR,<br class="">
Simon<br class="">
<br class="">
<br class="">
<br class="">
On 05.10.22 17:55, Michel Stam wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:4C7C12CC-241C-400B-AF82-D6F663379970@ripe.net" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
Hi Simon,
<div class=""><br class="">
</div>
<div class="">Thanks for the rundown, that
helps.</div>
<div class=""><br class="">
</div>
<div class="">The Atlas measurement code
uses something different than nc, but that
isn’t really relevant, the process is
roughly the same.</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">I have a question, though.
Both netcat and openssl wait for the 220
to continue. If a timeout would occur
during the STARTTLS phase, or before the
220, would this differ from a conclusion
perspective? In other words, is it
necessary to test once for the 220 to
appear (or a timeout), then another time
to see if the STARTTLS completes? Could
this be folded into a single test that
does a 220, then the STARTTLS and will
report error when there’s a fail in the
process?</div>
</div>
<div class=""><br class="">
</div>
<div class="">As to the TCP traceroute, this
is something used by people to measure
service availability using Atlas. It isn’t
something I came up with perse, but yes
its to measure response time as well as
availability of the service at the TCP
level.</div>
<div class=""><br class="">
</div>
<div class="">With regard to additional
check such as DANE, these lie somewhere
between DNSSEC and TLS measurement. I’ll
make a note of this, thanks for the
suggestion.</div>
<div class=""><br class="">
</div>
<div class="">As to measurements in general,
all currently support IPv6 to my
knowledge. I agree that new ones should
support this too.</div>
<div class=""><br class="">
</div>
<div class="">Regards,</div>
<div class=""><br class="">
</div>
<div class="">Michel</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 1 Oct 2022, at 17:11,
<a href="mailto:ripe.net@toppas.net" class="moz-txt-link-freetext" moz-do-not-send="true">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="">
<blockquote type="cite" 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?</blockquote>
<blockquote type="cite" class="">
<div class="">The intent of
the measurement would be to
validate whether an SMTP
server is:</div>
<ul class="MailOutline">
<li class="">reachable</li>
<li class="">responsive</li>
<li class="">capable of
secured transmissions</li>
</ul>
</blockquote>
<br class="">
First, let's define the
testmethod. In my opinion:<br class="">
<br class="">
- reachable<br class="">
3-way TCP Handshake with target
on tcp/25 successful?<br class="">
<br class="">
- responsive<br class="">
when establishing and SMTP
connection, does the smtp-server
signalize readiness of the
service (SMTP 220)?<br class="">
<br class="">
- capable of secured
transmissions<br class="">
when sending an EHLO, the server
will tell us his features.
250-STARTTLS should be there.<br class="">
<br class="">
<br class="">
For all three checks, it's the
easiest to use netcat.<br class="">
<br class="">
Reachability:<br class="">
<blockquote type="cite" class="">$
nc -vz <a href="http://mahimahi.ripe.net/" class="" moz-do-not-send="true">mahimahi.ripe.net</a>
25<br class="">
<a href="http://mahimahi.ripe.net/" class="" moz-do-not-send="true">mahimahi.ripe.net</a>
[193.0.19.114] 25 (smtp) open</blockquote>
<br class="">
Note, that we have not measured
the response time. That's why
you wanted to use TCP
Traceroute, right? We can also
go with TCP Traceroute here.<br class="">
<br class="">
<br class="">
Responsiveness (wait for 220):<br class="">
<blockquote type="cite" class="">$
nc -C <a href="http://mahimahi.ripe.net/" class="" moz-do-not-send="true">mahimahi.ripe.net</a>
25<br class="">
220 <a href="http://mahimahi.ripe.net/" class="" moz-do-not-send="true">mahimahi.ripe.net</a>
ESMTP Sat, 01 Oct 2022
15:25:22 +0200<br class="">
quit<br class="">
221 <a href="http://mahimahi.ripe.net/" class="" moz-do-not-send="true">mahimahi.ripe.net</a>
closing connection<br class="">
</blockquote>
<br class="">
You might want to use the -w
option here, to specify a
timeout.<br class="">
<br class="">
<br class="">
capable of secured transmissions
(send EHLO and check response):<br class="">
<blockquote type="cite" class="">$
nc -C <a href="http://mahimahi.ripe.net/" class="" moz-do-not-send="true">mahimahi.ripe.net</a>
25<br class="">
220 <a href="http://mahimahi.ripe.net/" class="" moz-do-not-send="true">mahimahi.ripe.net</a>
ESMTP Sat, 01 Oct 2022
15:54:04 +0200<br class="">
EHLO <a href="http://p123456.probes.atlas.ripe.net/" class="" moz-do-not-send="true">p123456.probes.atlas.ripe.net</a><br class="">
<a href="http://250-mahimahi.ripe.net/" class="" moz-do-not-send="true">250-mahimahi.ripe.net</a>
Hello <a href="http://p123456.probes.atlas.ripe.net/" class="" moz-do-not-send="true">p123456.probes.atlas.ripe.net</a>
[123.123.123.123]<br class="">
250-SIZE 52428800<br class="">
250-8BITMIME<br class="">
250-ETRN<br class="">
250-PIPELINING<br class="">
250-PIPE_CONNECT<br class="">
250-STARTTLS<br class="">
250 HELP</blockquote>
<br class="">
<br class="">
To check the Certificate
validity and if encryption is
indeed successful, we can use
OpenSSL:<br class="">
<blockquote type="cite" class="">$
openssl s_client -starttls
smtp -connect <a href="http://mahimahi.ripe.net:25/" class="" moz-do-not-send="true">mahimahi.ripe.net:25</a><br class="">
</blockquote>
(output to long, i stripped it)<br class="">
<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">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.</blockquote>
Yeah, as far as i know, STARTTLS
is also used for imap, pop3,
xmpp and ftp (ftps, not sftp).<br class="">
<br class="">
<br class="">
As i said before, there are
additional e-mail security
features that we could check.
There's MTA-STS, where we would
have to perform a combination of
HTTP and SSL check. Also, there
is DANE, where we would perform
a combination of DNS and SSL
check (including DNSSEC). But
DANE can be used for other
protocols as well, not only
SMTP. DNSSEC/DANE are perhaps
worth a separate check type.<br class="">
<br class="">
Last but no least, we should
check for Forward-confirmed
reverse DNS and matching SMTP
banner, which is a combination
of DNS and netcat check. This
would be a reasonable part of
every smtp measurement.<br class="">
<br class="">
<br class="">
Please note, that the creator of
the measurement should either
specify the exact mailserver
FQDN, or the target Domain. In
the latter case, an MX record
lookup has to be performed
before the measurement starts,
not while the measurement is
running. Otherwise it could
cause credit consumption
trouble, if suddenly multiple mx
records are added the domain,
while the measurement is
running.<br class="">
<br class="">
Oh, and please make the SMTP
measurement IPv6 capable :)<br class="">
<br class="">
<br class="">
BR,<br class="">
Simon<br class="">
<br class="">
<br class="">
<br class="">
On 29.09.22 11:50, Michel Stam
wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:2D29819A-6B48-44F8-A15A-2F04B2912F29@ripe.net" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" 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="moz-txt-link-freetext" moz-do-not-send="true">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 class="">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 class="">I would like to
understand if there are
particulars you are looking
for that need to be
considered outside of
STARTTLS support?</div>
<div class=""><br class="">
</div>
<div class="">Regards,</div>
<div class=""><br class="">
</div>
<div class="">Michel</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div class="">On 23 Sep
2022, at 17:08, <a href="mailto:ripe.net@toppas.net" class="moz-txt-link-freetext" moz-do-not-send="true">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/" moz-do-not-send="true">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>
</blockquote>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</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>
</blockquote>
<br class="">
</div>
</div></blockquote></div><br class=""></div></body></html>