How to get traditional email clients to send email which appears normal in Gmail?

Question

A considerate friend informed me recently that emails I send (with Neomutt; could be Mutt or Gnus or Pine) look funny on his device:

Apparently Google doesn't invest much effort in properly formatting standard RFC 2822 text emails.

Given that Gmail has more than one billion monthly active users, it seems futile to blame them for the problem.

Is there something that I can do on my end to make my emails appear "normal"? I'm happy to use format=flowed which has somewhat unofficial support in Emacs; but apparently Gmail does not support it.

Another solution that comes to mind would be to pass my plain-text emails through some kind of Markdown parser, turning them into HTML and attaching this as an alternative format to outgoing emails. I haven't really thought this through, but it seems like it could work nicely because Markdown already supports

quoted text

and double-quoted text

using the standard >, >> prefixes. Perhaps the result would look even better than the emails that "normal" people send using their graphical email clients.

Do people do this? Can they do this (e.g. in Mutt/Neomutt)? What is the "standard" solution?

Answer 1

check out 'plainMail2HTML' which uses python's docutils to convert 'markdown' to 'HTML'. So far I've found the results to be encouraging. Find out more at the github repository.

Bye bye

Answer 2

More on the markdown method

In my question I missed some prior discussion of the same topic, for example another UL question, Send email written in markdown using mutt. That question seems to be really about how to do this on a shared computer or some other situation where it is not possible to modify the "sendmail" used by Mutt, but it links to a solution which should fit my use case.

The solution is from 2009, from dgl.cx, HTML mail with mutt using Markdown, which binds a keystroke in the Compose screen to create a specially-named HTML attachment via a fake 'editor'. Then a fake sendmail, when it sees this specially-named HTML attachment, creates a multipart/alternative structure and passes it to the real sendmail.

One of the comments in the above UL discussion links a "No Substance" blog post, mutt's secret sauce, which I found very helpful as well.

Both approaches solve some problems that arise in more primitive treatments:

1. How to create proper multipart/alternative attachments. We would like to send multipart/alternative with both text/plain and text/html, so that people using Mutt can see the original source, and people using Gmail can see the HTML. Markdown is ideal for this in that the the source is also human readable. However, apparently outgoing mails with multipart/alternative structure have only fledgling support in NeoMutt. The dgl.cx post solves this problem by having a fake sendmail create a multipart/alternative structure. The No Substance post has a fake sendmail which additionally does the Markdown parsing. With NeoMutt's new support for multipart/alternative, maybe an even better solution will be forthcoming in which a fake sendmail will not be necessary.

2. How to allow previews. If we're going to be attaching an HTML version, which is easy enough by switching to an alternate Sendmail, then it would be good to see how this looks before the message is sent. As pointed out in the No Substance post, this can be done by monitoring the file in which Mutt stores draft messages, whose location is configured with the "postponed" variable. For the dgl.cx solution, this is not really necessary since the HTML version already appears as an attachment and can be opened manually.

I haven't tried either solution yet but I'm leaning towards the one from dgl.cx as it seems simpler.