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.
Like back then, I do worry about blocking servers that may not have been used for badness. If it's only that they COULD be abused, it's a little more grey area to reject mail from them versus they HAVE been abused.
I don't think it's grey area at all.Just because someone / something /could/ commit a crime (send spam / steal something) does *NOT* mean that they will do so.
But also, their server, their rules. Meaning I think Microsoft has the right to do this, regardless of how we might feel about it.
I think we as an industry SHOULD PUSH BACK VERY HARD on anything along the lines of "too old to play" mentality.
I'm okay if Microsoft wants to say "you must use one of these supported communications methods to play". I strongly suspect that even the venerable RFC 821 SMTP from 1982 will likely suffice for a very long time.
To re-iterate, I think the "too old to play" mentality is a VERY BAD THING and a VERY SLIPPERY SLOPE.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
