Bug#532150: Bug#865792: reportbug: Allow an arbitrary MUA to be configured (patch)
David Steele wrote:
> chaica wrote:
> > Allowing custom muas outside supported muas exclude the possibility to give
> > feedback to the user about what happened *after* reportbug gave the bug
> > report to the mua. How can reportbug know if your script/custom software is
> > available on your system and efficiently working ? What error code should
> > reportbug wait to inform the user the bug report failed to be sent ? We
> > chose to only support some muas in order to provide a better efficienty
> > using reportbug. And we did it because some users reported bugs *because*
> > reportbug was not alerting them when the mua failed and finally was not
> > doing its job.
> > I think the main idea is to guarantee the user that the bug report will
> > efficiently be sent through every options offered by reportbug.
> My apologies - I submitted the patch in 865792 before spotting this entry.
>
> The patch supports the mua_exists() call, and has error handling/detection
> in the custom case that is equivalent to the supported muas.
>
> Personally, I'd expect a decent mua (vs. an mta) to show the user what it is
> going to send/has sent. In any case, you could make it clear that custom mua's
> are the buyer's responsibility.
David, thank you for your patch/MR and input on this. Here my thoughts so far. I'm hoping to find time to get a solution into reportbug soon.
The current MUA support in reportbug has two main limitations:
1. It only allows a small fixed set of MUAs.
2. It does not support passing attachments to the MUA.
Ideally, I would like to remove both limitations. To not regress on the points Carl was making, the interaction between reportbug and MUAs must follow a certain protocol so reportbug can know about:
(a) the MUA is installed and can be called
(b) calling the MUA actually worked or failed.
(c) optional: the MUA supports passing attachments on the command line
Re (a): I like the mua_exists() part from your MR. (I'd like to avoid the mua_version thing, however; see below.)
Re (b): Exit code zero means success, anything else means failure.
Re (c): We could add a supports_attachment property to the Mua class. MUAs supporting attachment passing could set this to True. For custom MUAs I think we'd still need to set this to False since there is no way to detect this. Then reportbug could simply list the desired attachment files, asking the user to attach them manually. (I'm not sure if I can make this work in the GTK ui, so perhaps such a property is not useful. We can leave it out in the first step.)
To make users aware that custom MUAs are under their own responsibility, I think it makes sense to have them clearly distinguishable from supported MUAs in the configuration file, and explicitly document this responsibility. Distinguishability could be enforced by requiring that custom MUAs always be specified as the full path to the executable. Or we hardcode a specific path such as $HOME/.reportbug/custom-mua and call it "custom" in the config file.
As further restrictions (to be documented), custom MUAs must understand a --version command line option. Making this configurable on the reportbug side just clutters the configuration file with stuff that reportbug does not really care about. This should be avoided. For people writing wrapper scripts for their own MUA this restriction should not be any problem.
There are multiple options when it comes to how reportbug can pass email content to a MUA. This can be (assuming attachments are desired):
- a complete mime/multipart email template including the attachments,
- a non-multipart email template and a list of attachment files
- headers, content, attachments all specified in separate command line arguments
- a single mailto URL according to RFC2368 / RFC 6068
Reportbug also cannot know which one of these is the best for a user's custom MUA. The second is the closest to what reportbug is currently passing to its Mua.send() method, so it could just stick to that for custom MUAs. We could provide an example wrapper script in /usr/share/doc/reportbug/examples/custom-mua that turns this into a mailto URL and calls xdg-open with that. Users could copy that somewhere and make it executable. It would be great if this scheme would even allow using webmail services as mailto handlers. Hello, gnome-gmail.
Custom headers have also been mentioned as a potential problem. The most important seems to be X-Debbugs-CC. The BTS supports this as a pseudo-header, so it should be easy to set this as a pseudo-header from reportbug, too.
Comments, suggestions?
Reply to: