xdg-email: Keep or throw away --attach ?

This issue related to #177 and !58 but is not about the CVE.

xdg-email --attach is useful. period. but …

… the underlying implementation is Thunderbird specific (and broken) and supporting other clients would add a lot of complexity as there is no standard, de-facto standard or even semi-standard way of calling a mail-client in a way that attaches a file.

The current implementation has the following problems:

• The way the filepath is passed is an exploitable footgun.
• ', , and probably some other characters are not usable as filenames, solvable by switching to file: URIs.
• Thunderbird and Icedove have well-known desktop-file names, other mail-clients aren't that lucky,detecting them will probably turn into a mess
• How do I know that the configured mail-client supports the --attach option (if the answer is testing if its TB or ID then why use xdg-email at all)
• xdg-email is a very bad xdg-open remake without a lot of the improvements that went into xdg-open
• …

Throwing away

Throwing this option away will definitly break some workflows. xdg-email would turn into something that assembles a mailto: address that gets handed over to xdg-open and done.

Keeping it

Keeping it would mean someone has to fix …

• the issues directly related to the run_thunderbird function.
• communicating if --attach is possible (i.e. with a --can-attach option)
• the issue on how to deal with other mail-clients
• let xdg-open and xdg-mime do their job in order to reduce the complexity in xdg-email

Problem here is that someone has to do that and I know that I won't have enough time for this in the near future.

In any way

• document the intended use of xdg-email
• move the interpretation of the MAILER Variable to xdg-open, it is the script that handles mail URIs from all over.

What to do?

To be honest: I really don't know … both sides have pros and cons I'm levng this here for discussion.