Re: [atlas] RIPE Atlas SMTP Measurement

[Simon Brandt via ripe-atlas]

Hi everyone,

multiple times, i wrote about "enhanced SMTP Status Codes". That was nonsense. 
What i meant were Extended SMTP commands (e.g. 250-STARTTLS). Sounds similar, but is 
something different:

ESMTP - https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#Extensions
Enhanced Status Codes - 
https://en.wikipedia.org/wiki/List_of_SMTP_server_return_codes#Enhanced_status_code

My apologies!


Best regards,
Simon



On 23.09.22 17:08, Simon Brandt via ripe-atlas wrote:

Hi Michel,

>Are we monitoring the Internet or monitoring a service using the proposed SMTP 
measurement?
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).

>Can we achieve the first 2 items of this measurement by doing a TCP traceroute 
on port 25?
I would say no. Using TCP Traceroute, you can may check for 
reachability/responsiveness of the host, but not the actual service (smtp).

>Does the SSL measurement cover the intended use cases?
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 _does_ support SMTP and STARTTLS. So you could probably modify the 
existing SSL measurement.

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,
Simon



On 23.09.22 16:04, Michel Stam wrote:

Hi everyone,

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!

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.

The intent of the measurement would be to validate whether an SMTP server is:

  * reachable
  * responsive
  * capable of secured transmissions


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.

With this in mind, I am wondering:

  * Are we monitoring the Internet or monitoring a service using the proposed 
SMTP measurement?
  * Can we achieve the first 2 items of this measurement by doing a TCP 
traceroute on port 25?
  * Does the SSL measurement cover the intended use cases?
      o  Is it worth exploring STARTTLS support as an extension and what would 
the implications be?


Have a good weekend!

Best regards,

Michel

On 21 Sep 2022, at 00:11, Avamander <avaman...@gmail.com> wrote:

> 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.

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?

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.

Crutch solutions out in the wild shouldn't be a showstopper for measuring the 
ecosystem. (That is already quite neglected)

> What _objective_ risk/benefit analysis are you basing your opinions upon?

And you? What's the implication here about systems being as trigger-happy as 
previously described?

Because sure, at some point rate limits make total sense, but certainly not at 
the point where it would ban any potential RIPE probes.

>  Are you a systems administrator?

Let's not get into such measuring contests, even if it is the RIPE Atlas 
mailing list.

On Tue, Sep 20, 2022 at 11:42 PM Paul Theodoropoulos via ripe-atlas 
<ripe-atlas@ripe.net> wrote:

    On 9/20/2022 10:45 AM, Avamander wrote:

    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.

    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.

    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.

    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.

    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.

    Note, I run a probe myself. I don't block any RIPE Atlas traffic on my 
separate servers hosted on AWS, Oracle, and GCE.

-- Paul Theodoropoulos

    anastrophe.com <https://www.anastrophe.com/>

-- ripe-atlas mailing list

    ripe-atlas@ripe.net
    https://lists.ripe.net/mailman/listinfo/ripe-atlas

--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas