I still wish that text/enriched (RFC 1896) would prevail. It has none of the security problems of HTML, but almost all the features which HTML mail proponents claim they can’t live without.

Even ASCII-only forums and mediums have come up with informal markups for features like *bold*, _underline_, SPEAKING LOUDLY, etc. You might be so accustomed to these that you dont’t even see the codes anymore, but they are codes, and quite ugly too.

Because most people need formatting, plain and simple The font selection is a trivial client override, so shouldn't prevent rich text

Okey, thats valid point.. Formating indeed..

This threat comes up a lot...but I gotta say I HATE HTML emails. Luckily thunderbird converts most of them to a more or less plain text look but the conversion is never truly like plain text. Plain text looks so much nicer...

I think email would be a lot better if plain text were the only format possible.

> I think email would be a lot better if plain text were the only format possible.

When writing longer emails it helps to be able to emphasis words, section the email, quote, create bullet lists and hide long links behind a title. All of these would work nicely if email clients would support (and default to) markdown.

Attachments are sufficient for images, but with markdown I could still inline them when it makes sense.

Fonts/colors are very frustrating every time I compose emails and copy/paste text.

I agree, I think markdown would be a nice compromise between plain text and ugly HTML.

Strongly disagree. I can communicate with my colleagues much better if i can embed pictures, math equations, use highlighting, etc.

There are probably cases where plain text email is enough (linux kernel development seems to be doing fine), but once you enter corporate world HTML and all its goodies bring a lot of benefits.

(HTML) "Please have a look at this table (table pasted inline to email) and compare the results with previous run (another table inline)"

(plain text) "Please have a look at attached table (table1.xlsx) and compare the results with previous run (table2.xlsx)"

Sure, both bring the same information but the former gives you all the information immediately.

> if plain text were the only format possible

Hard to enforce? <p>this</p> is text too.

A few <p>tags</p> in a larger text are ugly but not too bad. Most HTML e-mails are 200 lines of tag soup without any content, then 100 lines of content wrapped in several layers of tags and finally 50 more lines of tag soup without any content.

Don't forget that the parts you are trying to read are actually text embedded in images

Monospaced?

I use Mutt as my primary mail reader and have my mailcap configured to use a text-mode browser to deal with HTML mails. For images and other binary attachments, I copy them into a directory that’s accessible over the web so I can view/download them that way. This (mostly) works.

My biggest annoyance is that I subscribe to a number of different Mailchimp-powered mailing lists (voluntary groups, NGOs, music promoters, etc.) and I regularly receive emails where the subject line doesn’t match the body of the email as displayed by Mutt. The reason is that I receive a multi-part message with both plain text and HTML attachments. However, only the HTML part contains the relevant text; the plain text part is a copy of a previous email (in some cases a year old).

I’m guessing there’s something in the Mailchimp UI that makes it easier for organisations to load a previous email and use that as a template to send the next message – except that they don’t seem to notice that they also need to update the plain-text part. If they’re only going to edit the HTML part, it’d be better for subscribers like me if they didn’t send any plain text version.

I’ve emailed the senders to let them know about this issue. One environmental NGO replied to say they’d check the plain text version next time while neither music promoter replied at all.

I'm using Neomutt and I had the same issue with incomplete messages. I tried many ways to convert HTML emails to text for the internal pager, currently I use rust-html2text [1] with some tricks and it's the best result so far.

There is still some issues with Links references and not displaying preview elements so it's a little experimental, I created a Gist with my config and notes [2].

[1] https://github.com/jugglerchris/rust-html2text

[2] https://gist.github.com/tkapias/b0df814c40daf642209b8023f80f...

They probably clone last campaign to edit a new one and only change the HTML version. There's a button that “translates” HTML version into txt, but if not pressed, old text remains in plain text version.

Markdown is actually a good format for email messages. (Not marketing brochures as most email is)

Kind of. Markdown is a superset of HTML which means all HTML tags are valid markdown.

I've been using Emacs continuously for almost three decades, 99.9999% of the time text-only (whether Linux console, X terminal console, xterm, or SSH client) on a remote server. My email client is VM, written in Emacs Lisp. I've used it to read mail for almost as long as I've used Emacs.

VM (and ancillary tools, like Personality Crisis and mairix)

* does a great of job displaying HTML messages with Emacs's integrated W3M browser engine. For the very few that it doesn't, one keystroke sends the message to my web browser running locally.

* sends URLs I select (all from the keyboard) to the web browser (it doesn't use the add-number method; rather, W3M's built-in navigation keystrokes are available, including Tab and Shift-Tab for moving between links)

* opens images and attachments

* auto-adjusts the From: line of outgoing messages depending on the recipient

* archives messages to various folders using various criteria

* searches my archived mail at lightning speed

Of course, I can write Emacs Lisp code of my own to extend any or all of the above.

VM isn't perfect but, overall, I really feel like I have a superpower for email handling with it.

I use mu4e in Emacs as my mail client, along with org-msg and org-mode, and there's nothing better:

* Compose emails in org-mode markup (like Markdown but better) and auto-generate plain-text and HTML email on export, complete with syntax highlighting for code snippets

* Use your favorite text editor's keybindings to compose email: emacs, evil-mode (vim-style), meow (kakoune-style)

* Lightning-fast local search, offline sync with no Internet connection necessary

* Saved searches and bookmarks which allow for fast handling of mail based on given patterns

* Capture emails with org-capture and turn into todo items, links, notes, or reminders

* Tight integration of your mail system with your note taking system, your personal knowledge base, bibliographic manager, and so on (everything in emacs)

* Scriptability which can automate the boring stuff, like composing greetings ("Dear so-and-so,"), context-dependent signatures, and the like.

It's nice to see so many people still understanding the benefits of plain text email.

I wish thunderbird's "simple HTML" view option was closer to plain text: one locally selected font, non-obscured links, while still rendering images inline...

My email workflow is: write plain text in vim, select all gq and yank (ggVGgqvggy), past into mail client plain text mode, done

I sometimes also tweak the gq wrapping before sending it off.

I have a similar work-flow, but I made a shell function for that (an "alias") called `email`:

    email ()
    {
        export TMP_EMAIL_FILE=$(mktemp -t email_XXXXXXXXXX.eml) && vim -c 'set filetype=mail' -c 'set tw=72' -c 'set spell' "${TMP_EMAIL_FILE}" && {
            cat "${TMP_EMAIL_FILE}" | xsel -ib
        }
    }

Feel free to copy, use and modify it. :)

Still using plain text for almost all emails and configured Thunderbird to display plain text first (and then using allow html temp for unreadable junk...)

In the new Outlook for Mac I still have to find a way to create a plain text message.

Maybe it is the way described in https://useplaintext.email/#outlook-desktop . Or is that exclusively for Windows?

As described, most probably a Windows Outlook specific option.

I believe something similar is still present in the "Legacy Outlook" for Mac, but nothing like it in the new Outlook.

Markdown emails are the future!