So, you're right - and the point you raise at the end (with your illustrative example) is a good one. It would be wrong for HN software to silently not deliver

So, you're right - and the point you raise at the end (with your illustrative example) is a good one. It would be wrong for HN software to silently not deliver your message to me without telling you - just because tó was on some blacklist for some reason. If it's possible to write "Your message could not be delivered" when messages match the blacklist (even leaving the sender to guess at what they did wrong) it would be better. As a practical matter if you haven't built the infrastructure into your clients to tell the sender that their message won't be delivered, none of the choices the platform operator has seem great: - Silently drop a few kinds of messages without informing sender. Seems bad for the reason you outlined. - Silently modify messages before delivery, modifying them so they won't crash clients. This seems potentially very wrong. - Deliver messages even if you know for sure they will crash the client upon view Doesn't seem great to me either. I guess the real solution is to have robust forced-upgrade on the client (after all, it's your software, you're responsible for it and if you build it to include updates that it is on you) but some users object to that and I suppose they could be justified - it is also a massive responsibility. I guess there really aren't any perfect answers here.