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.
Cheers,
Cameron Simpson <c...@cskk.id.au>
