HTML mail which isn't handled correctly by 'auto_view text/html

Wed Feb 6 02:00:48 UTC 2019

On 05Feb2019 22:10, Chris Green <cl at isbd.net> wrote:
>I am getting notification E-Mails from DPD which aren't handled
>correctly by 'auto_view text/html' in my muttrc and 'text/html; lynx
>-dump %s; copiousoutput; nametemplate=%s.html' in .mailcap.
>
>Presumably it's simply that there is no 'text/html' string in the
>headers, I just get to see the raw HTML.  In fact there is the
>following:-
>
>    ...
>    ...
>    ...
>    Subject: Your order 3179771 is due for delivery by DHL Parcel UK
>    Content-Type: multipart/alternative;
>            boundary="--boundary_145134_db6b4c85-2751-452f-bf4b-c56010b07587"
>    Message-ID:
>    <eaa14d01-a923-4fcd-8ff1-88ed5b135903 at BH-EXCH01.business-post.com>
>    Status: RO
>    Content-Length: 20807
>    Lines: 285
>
>    Content-Type: text/plain; charset="us-ascii"
>    Content-Transfer-Encoding: quoted-printable
>
>    <!DOCTYPE HTML>
>    <html>
>    <head>
>        <!-- Define Charset -->
>    ...
>    ...
>    ...
>
>So that would explain it!  Is there any way to manually ask mutt to
>treat this as text/html?

Kinda.

Firstly, is that really the entirely of the relevant headers? No 
text/html or multipart/mixed? DHL are really sending HTML notifications 
(ugh!) identified as text/plain? That is a new low.

(My previous low is the many senders who send multipart/mixed with 
either the HTML duplicated in the text/plain half or outright absent - 
empty text/plain half.)

So: are DHL sending _only_ an text/plain section or both text/plain and 
text/html? In my experience it is usually the latter.

Scenario A: Both text/html and text/plain, but the text/plain contains HTML. I get 
this a lot. I have this in my muttrc:

    ############################
    # 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 uses "alternative_order text/plain text/html" normally, but 
reverses that for some special messages: Apple Mail with attachments, 
and email from known bad domains and senders in my %htmlers mutt group, 
a list of specific know bad authors.

Scenario B:

If DHL really are sending HTML in a standalone text/plain body then 
you've got 2 choices.

The first is to act when you receive the email; if you're using procmail 
or something similar to file you email you could match these messages 
and modify the Content-Type: header to say "text/html".

The alternative is to match the message with mutt, and to set 
display_filter specially for this message. You could use your normal 
display_filter and use a message-hook to override it with the command 
from the mailcap ("lynx -dump").

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