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.)