text vs html

[Cameron Simpson]

On 09Jul2019 22:53, Fred Smith <fredex at fcshome.stoneham.ma.us> wrote:
>If I get an email with both text and html sections, according to
>my /etc/mailcap it seems to be getting processed like this:
>
>text/html; lynx -dump -vikeys -raw %s; copiousoutput; nametemplate=%s.html
>
>So, when someone sends email from outlook that contains a smiley face,
>it displays a "J" when viewing that mail. (apparently because outlook
>encodes a font change to some other font where "J" is a smiley face.)
>
>it seems to be following this recipe and decoding the html part even
>though there is a perfectly readable text part, containing a :-).
>
>does the order of statements in mailcap matter? should I change this:
>
>text/html; lynx -dump -vikeys -raw %s; copiousoutput; nametemplate=%s.html
>text/plain; copiousoutput
>
>to this:
>
>text/plain; copiousoutput
>text/html; lynx -dump -vikeys -raw %s; copiousoutput; nametemplate=%s.html
>
>Or is th is problem just because Outlook is broken and instead of
>issuing a font change should just embed the proper Unicode character?

Well, insanity on Outlook's part should always be considered, but...

The choice of text/plain vs text/html is controlled by your mutt config.  
The mailcap just says how to handle that choice.

I've got:

  auto_view text/html
  alternative_order text/plain text/html

The latter says to prefer text/plain to text/html.

This is great when it works. However, various clients and programmes 
send both text/plain and text/html but the text/plain half is rubbish.  
Often essentially blank, sometimes raw HTML, etc. So what I've got is 
actually more complex:

  ############################
  # alternative-order criteria
  message-hook . 'unalternative_order *; alternative_order text/plain text/html'
  # Apple Mail embeds attachments in the HTML part instead of outside the 
  # multipart/mixed
  message-hook '~h "X-Mailer: Apple Mail" ~X 1-' 'unalternative_order *; alternative_order text/html multipart/mixed text/plain'
  # senders who can't seem to master multipart/mixed, and send empty
  # or useless text/plain sections
  # or just badly badly formatted plain text, such as live.com etc
  message-hook '%f htmlers | ~f @no-reply at cc.yahoo-inc.com | ~f @outlook.com | ~f live.com | ~f @facebookmail.com' 'unalternative_order *; alternative_order text/html text/plain'

Which fires some message-hooks on each message to decide what to prefer.  
Of course, we start by preferring text/plain, but under certain 
circumstances we then override that to prefer the text/html because we 
know the source of the email is too stupid to make a competent 
text/plain section.

The "%f htmlers" matches email from an explicit list of source authors I 
know are bad in addition to the coarse rules matching various "modern" 
platforms.

Cheers,
Cameron Simpson <cs at cskk.id.au>