I don’t think there is a technical reason to change things, it’s a question of user expectations. Adding a user preference to disable the HTML part seems doable if somewhat annoying given how many bits of code it would touch (as with all new user prefs), but I’m not lining up to contribute it so it’s not the hill I’ll pick to die on 
6 Likes
Yeah. If only. I am pretty curmudgeonly on such issues, and I gave up on receiving plain text email at least a decade ago.
And RFC 2046? I’m an RFC 822 guy myself. 
If you’re going to go citing chapter and verse you should probably check out RFC4288 which is only a decade old instead of three decades old.
All that to say that there’s probably no good solution, and people who expect text-only email live in a world of hurt.
I’m Maximum Curmudgeon (and I normally use mutt as my mail client), and as long as there’s a text/plain variant available, I care not what else is floating around in the pot of crud that is a modern e-mail. I’ve got to agree that if we’re sending a text/plain variant and your MUA isn’t showing it, that’s something for you to discuss with your MUA of choice. Even I’m willing to concede that HTML would be the, in general, “preferred” format, so if you want plain text, talk to your MUA. I wouldn’t even recommend a user pref to say “send plain-text e-mail by default”, and my beard is as grey as they come.
5 Likes
My beard, in real life, is not grey. That said… My email tool chain involves a personally modified mailx, though, and HTML is viewed in source form until hand-modified.
But sending text/markdown with headers declaring it as text/plain could be annoying to someone who is particularly pedantic. (I am not very concerned myself.) And I can confirm Discourse does do that.
1 Like
Dear @pfaffman, RFC 4288 says:
All subtypes of multipart and message MUST conform to the syntax
rules and other requirements specified in [RFC2046].
1 Like
Sorry. I was mostly being silly. My point was that in my view including anything other than 7-bit ASCII in email is an abomination and should be ignored.
But, really, you should mostly ignore me.
2 Likes
----==_mimepart_57eec1754fb1b_613fb08d373ca061471a
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: 7bit
Actual headers for the text part of a multipart/alternative message. I’ve not seen (closely looked at) enough of Discourse’s email to know how it deals with non-ASCII in messages or SMTP line length considerations.
1 Like
That’s an interesting thought to have Markdown supported in email. I tried Markdown-here addon for Thunderbird, but it requires “a rich text editor” (AKA HTML email, which is yuck.) Then I found these thoughts on writing emails using Markdown that proposes to add a markup option to the Content-Type:
Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown
It sounds better, as the MUA can then format the markdown properly (although not many MUAs support Markdown at all, and other inconvenients mentioned in the article.) Best of both worlds would be to keep using text/plain, and automatically convert Markdown when reading, and not convert to text/html when sending as Markdown-here seems to be doing.
1 Like
Issues with email-in
(Feel free to split topic or move where appropriate)
I’ve been trying to reply by email whenever possible. Here’s an example of what I sent, and what the final HTML post looks like. I guess there’s room for improvement. First point would be to automatically remove the email signature (using .gsub('/^--\n(.*)\A/m', '')?) (also note that GPG-signatures seem to stick around) and fixing the line-breaks. I remember that Mutt has a very nice TOFU plugin to take care of cruft pretty effectively. Another issue is that normally, with email you always quote a bit of the message (when you’re well-behaved) which works like quoting here. But more often than not people are not well-behaved with email and end up quoting the whole thing. I guess top-posting is handled nicely, but I didn’t check.
Original:
click to view markdown source of the resulting HTML shown in screenshot below
We don't have a clear process yet. But it would go something along
these lines:
1. You upload your package to your personal account on
[git.do](https://git.devuan.org/)
2. You contact the [devuan-for-review
group](https://git.devuan.org/groups/devuan-for-review) so that they
fork it into the group for review and testing. You can contact them
using the #devuan-dev channel on Freenode IRC, or the DNG mailing list,
or by opening an issue in your package's page mentioning
`@devuan-for-review` (I guess this would work)
3. Once your package has been reviewed, corrected, etc., it will enter
the [devuan-packages
group](https://git.devuan.org/groups/devuan-packages) and
`experimental`. From there, if nothing special happens it should be
entering `unstable` after a couple of weeks, like Debian does. Usually
you would then become the maintainer.
Does that make sense? I guess we should submit a proposal for this
process, refine it, etc. I know @Centurion_dan was perplex about using
the `devuan-for-review` group, but I think it's worth a try.
--
_ _ We are free to share code and we code to share freedom
(_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/
Result:
Is this what you mean?
[details=click here to expand]lkj sdlkj sdlkfj sdlkf jsdlkf sdlkf [/details]
click here to expand
lkj sdlkj sdlkfj sdlkf jsdlkf sdlkf
1 Like
Right, thank you @pfaffman. Well I get the “we do not remove signatures”, but that means informing the users they need to skip their signature for replying by email unless you want to end up with ugly signatures across the board. 
It’s horrible. And the last place I worked required people to include postal address, fax address, office number, official title (or several), university icon, and I don’t know what all. A client who just switched to Discourse from a mailing list is already talking about disabling incoming email. His other solution is to hire people where labor is cheap to fix the stuff by hand.
2 Likes
Closing this as it is mostly implemented, no need to carry it open forever.
2 Likes