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? 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 <mailto: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 <mailto:ripe-atlas@ripe.net> > https://lists.ripe.net/mailman/listinfo/ripe-atlas > <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
