On 09Jul2019 22:53, Fred Smith <fre...@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-re...@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.

Cameron Simpson <c...@cskk.id.au>

Reply via email to