the more i think about it, the more i conclude that @sir is right and git forges aren’t the right answer.
I really want to like sourcehut, and these are excellent points in its favour.
One of my biggest concerns is that policy is hardcoded in to the software. e.g. the flat refusal to accept multipart emails merely because one part is HTML makes it impossible to discuss HTML attachments, and it actively impedes simple support inquiries via email (e.g. a users ML) which may result in a potential user looking at another project.
(Speaking as someone who’s been using the internet and writing emails almost as soon as they were able to read… the anti-HTML email crusade was lost decades ago.)
Had an argument on fedi a few weeks ago about it, he wouldn’t even accept any mechanisms for downgrading the HTML. There was also a patch offered to just quietly drop the HTML attachment, which was also rejected.
So, it’ll have to be some pressure indeed to make him change it.
I don’t know that there’s a solution to ‘no HTML email’ if “does not break DKIM signatures” is more important, then.
I do know that there should be an option to permit HTML email on a per-list basis, however.
@kaniini @Aerdan I really, really, really, really do not want HTML email on sr.ht. HTML is a pox on email and my goal is its elimintation from the internet. 99 out of 100 MUA vulnerabilities are email-related, for obvious reasons. It has no place in an MUA and I'm not going to let you burden subscribers of my lists with this awful mail format.
@sir @kaniini @Aerdan For *users* (not developers) who want to use a mailing list for help (e.g. alpine-users), it's unacceptable to bounce HTML email unconditionally. Not all clients support plaintext-only, and I really doubt that your project is going to change that. What leverage do you have over Apple, Microsoft, and Google? And, before you counter with "just use a different client", that is not an acceptable response either, *especially* in the case of lists designed for helping end users
this is mst3k