On Tue, Mar 28, 2023 at 11:44 AM Grant Taylor via mailop <mailop@mailop.org> wrote: > > On 3/28/23 10:19 AM, Al Iverson via mailop wrote: > > Eventually we have to stop allowing connections from misconfigured > > servers that are being exploited to do bad things. > > But what is "misconfigured"? How do you define that from a technical > level? How do you identify that? > > I agree that "servers that are being exploited" is something that can be > identified and evidence of bad behavior. > > I don't agree that simple mis-configuration without any exploit is a threat. > > E.g. what grounds do you have to block an Exchange 5.5 system someone is > running in their home lab protected from the internet and sending three > pieces of legitimate email a week? > > This seems tantamount to states saying that you can no longer drive cars > that are more than X years old. Even if they are in pristine condition. > > This is borderline oppression to me. > > Conversely "being exploited" is demonstrable and justifiable. > > We have an analogy in the legal system; the police can't act until > /after/ a crime has been committed. There are different and longer > processes that must be gone through to take action before a crime has > been committed to revoke people's rights. > > > This seems like a good thing to help both reduce the exploitable > > damage that can be done by these servers and also nudge their admins > > to wake up and patch up or shut down. > > Each admin has the right to run their email server the way that they > want to. -- This includes both running ancient software. This also > includes the right to refuse to allow a system to connect to send email. > > But how do you identify the aforementioned Exchange 5.5 from > contemporary Sendmail, both of whom are speaking perfectly valid RFC > compliant SMTP by all contemporary rules? > > And what grounds do you have to object to the Exchange 5.5 if it's doing > nothing wrong while allowing spam from a breached account behind the > contemporary Sendmail system? > > > Reminds me a bit of blocking open relaying mail servers back in the > > day. > > Not really. > > Blocking open relays was a binary test of openness and blocking if it > was open. Any MTA, new, old, beta code, or ancient bits must all adhere > to the test the same way. > > Simply deciding that something's too old to play is a very bad thing in > my opinion.
You're sort of trying to argue me out of agreeing with you. Here's the parallels I see. A Sendmail server so old that it can only be an open relay. Block it proactively? Or block it only after it has been exploited? An Exchange server so old that it HAS to be vulnerable to XYZ spam relay exploit. Block it proactively? Or block it only after it has been exploited? I find it a "grey area" because it feels wrong at some level to block without evidence of being exploited. Which is what I thought your point was. But we're all debating for debate club's sake. Who gives a shit what we think? It's not our call. Their server, their rules. I'm going to spend only the TINIEST amount of time shaking my fist at the sky. Regards, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
