The basics of /etc/mailcap on Ubuntu (and Debian)

February 25, 2020

One of the things that is an issue for any GUI desktop and for many general programs is keeping track of what program should be used to view or otherwise handle a particular sort of file, like JPEGs, PDFs, or .docx files. On Ubuntu and Debian systems, this is handled in part through the magic file /etc/mailcap, which contains a bunch of mappings from MIME types to what should handle them, with various trimmings. You can also have a personal version of this file in your home directory as ~/.mailcap.

In the old days when we didn't know any better, installing and removing programs probably edited /etc/mailcap directly. These days the file is automatically generated from various sources, including from individual snippet files that are stored in /usr/lib/mime/packages. Various programs drop files in this directory during package installation and then update-mime is magically run to rebuild /etc/mailcap. One should not confuse /usr/lib/mime/packages with /usr/share/mime/packages; the latter has XML files that are used by the separate XDG MIME application specification.

(As the update-mime manpage covers, it also uses the MimeType= information found in .desktop files in /usr/share/applications.)

As far as I know, the update-mime manpage is the sole good source for information about the format of these little snippets in /usr/lib/mime/packages and the eventual format of mailcap entries. The format is arcane, with many options and quite a lot of complex handling, and there is no central software package for querying the mailcap data; for historical reasons, everyone rolls their own, with things like the Python mailcap module. Update-mime and other parts of this come from the mime-support package.

(For fun, there are multiple generations of mailcap standards. We start with RFC 1524 from 1993, and then extend from there. On Ubuntu systems, the mailcap manpage doesn't document all of the directives that update-mime does, for example.)

A single MIME type may have multiple mailcap entries once all of the dust settles (plus the possibility of wildcard entries as well as specific ones, for example a 'text/*' entry as well as a 'text/x-tex' one). For example, on our Ubuntu login servers, there are no less than 7 /etc/mailcap entries for text/x-tex, and 13 for image/png and image/jpeg. In theory people using /etc/mailcap are supposed to narrow down these entries based on whether or not they can be used in your current environment (some only work in an X session, for example) and their listed priorities. In practice the mailcap parsing code you're using probably doesn't support the full range of complexity on a current Ubuntu or Debian system, partly because features have been added to the format over time, and it may simple pick either the first or the last mailcap entry that matches.

The Freedesktop aka XDG specifications have their own set of MIME association tracking standards, in the Shared MIME database specification and the MIME applications associations specification. These are used by, among other things, the xdg-utils collection of programs, which is how at least some GUI programs decide to handle files. I believe that these tools don't look at /etc/mailcap at all, but they do use MIME type information from .desktop files in /usr/share/applications and the XML files in /usr/share/mime/packages. They might even interpret it in the same way that update-mime does. The XDG tools and MIME associations all assume that you're using a GUI; they have no support for separate handling of a text mode environment.

Any particular GUI program might rely on the XDG tools, use mailcap, or perhaps both, trying XDG and then falling back on mailcap (parsed with either its own code or some library). A text mode program must use mailcap. I'm not sure how self-contained environments like Firefox and Thunderbird work, much less Chrome.

(See also the Arch Wiki page on default applications.)

Written on 25 February 2020.
« Webmail providers (and others) hiding user IPs was the right decision
The browsers are probably running the TLS show now »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Feb 25 00:20:38 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.