2020-06-13
An interesting combination of flaws in some /etc/mailcap handling
Somewhat recently we ran into an interestingly tangled issue around
/etc/mailcap and MIME handlers on our
Ubuntu 18.04 user login machines, one of those situations where
there seem to be multiple problems that when combined together lead
to an undesirable result. What happened is that we installed the
docx2txt Ubuntu package after
it was requested by someone, but then found that this broke at least
exmh's ability to display MS Office
'docx' file attachments. However, the interesting story is why.
As part of its package, docx2txt includes a /usr/lib/mime/packages
file to describe what it can be used to display, which then causes
update-mime to
update the MIME handling information in /etc/mailcap. Because
docx2txt prints what it converts to standard output, its mailcap
entry has the 'copiousoutput' tag, and also appears to set its
priority to 2, which is relatively low (5 is the default). The first
thing that goes wrong is that docx2txt has an uncaught typo in this;
it actually sets 'prority' to 2, leaving it at the default priority
of 5. Also installed on our Ubuntu machines is LibreOffice, and LibreOffice Writer also has
/usr/lib/mime/packages file. LibreOffice's entry for docx files
has priority 3, theoretically higher than docx2txt's (and a standard
condition to say 'I need to be in a GUI session to work'), but
docx2txt's typo means that docx2txt's mailcap entry should actually
be preferred over LibreOffice's.
The second thing that happens, which is at least unclear, is that
update-mime doesn't pass the priority field through to
/etc/mailcap. I think update-mime orders the generated /etc/mailcap
from highest priority to lowest, and assumes that programs that use
mailcap will pick the first matching entry. If this is what you're
supposed to do to handle priorities in mailcap entries, I couldn't
find anything that explicitly said it. Since this ordering doesn't
seem to be explicitly written up, it's at most folk knowledge and
you have to hope that the mailcap parser used by any particular
program follows this. Update-mime also doesn't reject docx2txt's
partially malformed mailcap line; instead it accepts it as an
entry with the default priority (and puts the 'prority' field
in the generated /etc/mailcap, where it may mislead you if
you're reading fast).
The third thing going wrong is that exmh turns out to have bad handling of mailcap entries that write their results to standard output, so that you can theoretically display it inline. What you would expect to happen is that exmh would run the handler (either automatically or on request) and then display the result inline. Instead, it has a little display for that attachment that looks like you can't do anything (normally it will say 'you can view this with ...', so you know the section can be handled), and if you actually ask exmh to run the mailcap handler to generate the output, it writes the generated output to its standard error (which almost certainly isn't connected to anything useful). Given that this is spectacularly useless, exmh clearly hasn't been used very much with mailcap entries that want to do this instead of running an external program that will display things on its own.
Exmh's bad handling of 'copiousoutput' mailcap entries wouldn't
be an issue except for the mangled priority field of docx2txt;
without that, exmh picks LibreOffice instead (which works fine).
Docx2txt's bad 'prority' field wouldn't have persisted if update-mime
(or some other tool) checked for and rejected improperly formed
mailcap entries; instead update-mime covered up the problem and
increased docx2txt's priority over what it had been intended. It
took a cascade of flaws to expose this issue.
(Our solution was to uninstall docx2txt again. It's not important enough to break exmh for people using it, and anything else that may also have problems with such an entry. Now that I understand the issue, I will see if I have enough energy to file a Debian bug report against docx2txt, which still has the bug in the current package source. Of course it will be years before any bug fix is available in Ubuntu.)