[atlas] RIPE Atlas SMTP Measurement
- Previous message (by thread): [atlas] RIPE Atlas SMTP Measurement
- Next message (by thread): [atlas] RIPE Atlas SMTP Measurement
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
ripe.net at toppas.net
ripe.net at toppas.net
Fri Sep 23 17:08:31 CEST 2022
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 <avamander at 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 at 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 at ripe.net >> https://lists.ripe.net/mailman/listinfo/ripe-atlas >> >> -- >> ripe-atlas mailing list >> ripe-atlas at ripe.net >> https://lists.ripe.net/mailman/listinfo/ripe-atlas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20220923/7162c484/attachment.html>
- Previous message (by thread): [atlas] RIPE Atlas SMTP Measurement
- Next message (by thread): [atlas] RIPE Atlas SMTP Measurement
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]