If they are receptive to feedback and clearly want to do better, I would be kind and explain why I had suggested it not be there in the first place and cite this as an example.
If they were being adamant or denying it was their fault, I'd probably be really quiet and just make subtle remarks about how it would have been better if they listened.
(Was interested to see what you were up to these days, which is how I stumbled on it).
But don't worry, you're not the first to mention it. I suppose I should just fix it and deal with the spam like normal.
I liked the unintended effect of cutting down on spam. I guess a lot of spam bots are written on top of standard libraries that reject bad certs. :)
Also, this was ironically a great way to publicly call someone out for a seemingly bad decision without being cruel about it, so props to you!
This is intriguing. I'm going to remember this but I'm too anal about perfect A+ TLS and renewal is already fully automated these days anyway :-\
I wonder if one could setup their TLS stack to get this effect without the tradeoff...
Also, if y'all do this, it probably won't work because the spammers will start ignoring expired certs.
Yeah, even if you could find a way to deny the spammers via esoteric configuration, it'll just make them realize they forgot to turn off TLS validation anyway (which is clearly what they meant to do)
(at least partly tongue-in-cheek) will it support DDL too? can I INSERT infra? or is this a read-only endeavor? :)
If someone does 'DROP TABLE ec2.instances', what exactly are they trying to accomplish? Do they want to terminate every ec2.instance? Should we let them?
Questions like that make write access very difficult.