I've looked into some other program for how they handle mailcap rules. The RFC deliberately doesn't discuss security, and not all projects seems to be aware of the problem. If mailcap is supposed to be standard and interoperable (and not a security nightmare), we need a central place for such considerations, be it the mailcap(5) man page or somewhere else.
Here's what I would recommend to do: 1) Document that users must keep %-escapes in mailcap rules out of single/double/back-quotes because it cannot be done safely and it is the job of the program parsing mailcap rules. Command substitution containing %-escapes must be done with $(...), and not with `...`. If (for some reason I can't imagine) users want to put a %-escape inside double or back quotes, they should assign it to a variable (without quotes) and than reference the variable inside the quotes. 2) Document that mailcap parsers must quote %-escapes expansions if necessary (see bash printf %q), to make sure that they are not split in the wrong places, and that *any* shell-special punctuation is treated literally by the shell. 3) File bugs for every debian package not following rule #1 and #2. 4) Recommend mailcap parsers to provide an option to replace shell-special punctuation with a safe replacement character. This would prevent command injections even if rule #1 is not observed. Please note that without either #1+2 or #4 in place, there is *no way* to avoid command injection (if you have any doubts about this let me know). And even enforcing #4, we cannot ensure compatibility unless we prescribe a specific policy about quotations. See also the section about mailcap security in the mutt manual: http://www.mutt.org/doc/manual/#secure-mailcap Slightly off-topic, I'm also seeing different ways to specify a path search of mailcap files via environment variable: - RFC-1524 prescribes MAILCAPS - mailcap(5) doesn't mention it - gnu mailutils uses MAILCAP (no final S) - s-nail uses MAILCAPS - mutt doesn't mention it Maybe it would be useful to document the "debian" way about this too, in mailcap(5).
