On 20Jul2015 16:11, m...@raf.org <m...@raf.org> wrote:
Cameron Simpson wrote:
In particular, I maintain a mutt group "htmlers" to track specific
senders which send useless plain text components. Keeps the condition
readable. [...]

another approach is to automatically run emails through a filter
that replaces multipart/alternative + text/plain + text/html attachments
with just the text/html attachment if the text/plain attachment is empty
or contains the phrase:

 Your email client does not support HTML email

the attached perl script can be used with procmail to achieve this without the
need to know in advance who uses email clients that don't understand the
meaning of the word "alternative".

but it is drastic in that it modifies the emails before you see them.
you might see that as overkill and you'd probably be right. :-)

I'm loathe to modify inbound emails beyond adding headers. (*) I prefer to adapt at display time, where I can see why things are mangled, than at filter time where the mangling happens irreversably.

(*) Though I _do_ rewrite From: and Subject: headers on the way in in some circumstances (**), though I leave an X-Old-{From,Subject} behind with the original in case of nonsense.

(**) Fixing up From: for DKIM mangling and undoing some RFC2047 text in Subjects.

Cheers,
Cameron Simpson <c...@zip.com.au>

Reply via email to