Software Freedom Conservancy: Give Up GitHub: The Time Has Come!

Most mailing list archives I see have neither.

> That's kind of a "you" problem. Some people do, and some people don't. And those who don't can usually follow better through the WebUI and use the aforementioned Reply to thread button

Well no, it's not a 'me' problem. It's blinding obvious if you open a PR on Github whether it has been merged or not. Instead open a random patch email on a mailing list archive and try to guess.

> Reject text/html and you don't have spam.

Have you actually ever seen a mailing list? I'm starting to doubt it, with statements like that.

> What in the everloving bleep?! No mailserver should modify an emails content unless there's good reason (like a virus) because that will mess up PGP or – in corpo world – S/MIME signatures, so I somewhat doubt there's a lot of this behaviour.

What they 'should' do according to you is irrelevant - vast majority of corporate email servers do exactly that, and there's diddly squat you can do about it as an employee.

I complain about this every couple of months. We use o365 and have enabled Safelinks. Safelinks corrupts email messages to make what appear to be URLs, proxy URLs for the same resource. It does this in at least text/html and text/plain parts. The replacement has a pattern that you can use to undo this in your mail reader (using a preprocessing script) with a low false positive rate. Another broken feature o365 has is temporarily replacing attachments with dummy ones while the original attachments are being scanned for viruses. If you notice this in time, you can go back and undelete the message (even if it was expunged) and get the attachment after it has been cleared. There are other broken features of this service not related to corrupting messages as well. I think they intentionally support only limited uses for email, which they think are common and don't care much about whatever they break for less common cases. Good luck trying to get an exception from your security people to opt out of this brokenness, even if your your case, the threat is extremely small and the brokenness causes more grief on average. They is more brokenness coming. They recently notified people about an attachment blocking feature that purports to block attachments of types on a blocklist, without providing a definition of how they determine the types of attachments. They don't say if they use Content-Type, Content-Disposition (from filename) and/or actually scan the attachment to determine the type, nor how that data actually maps to their list which were not standard mime type names. For people using the web interface there is more brokenness related to charset and no support for format=flowed.