<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 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><blockquote type="cite" class=""><div class="">On 20 Oct 2022, at 17:30, Michel Stam <<a href="mailto:mstam@ripe.net" class="">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="">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="">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://lists.ripe.net/mailman/listinfo/ripe-atlas" rel="noreferrer" target="_blank" class="moz-txt-link-freetext" moz-do-not-send="true">https://lists.ripe.net/mailman/listinfo/ripe-atlas</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://lists.ripe.net/mailman/listinfo/ripe-atlas" moz-do-not-send="true">https://lists.ripe.net/mailman/listinfo/ripe-atlas</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="">ripe-atlas@ripe.net</a><br class="">https://lists.ripe.net/mailman/listinfo/ripe-atlas<br class=""></div></blockquote></div><br class=""></div></body></html>