Open Bug 1545930 Opened 1 year ago Updated 2 months ago

API to send messages

Categories

(Thunderbird :: Add-Ons: Extensions API, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

People

(Reporter: Fallen, Unassigned)

References

Details

Attachments

(1 file)

It would be great to have an API to send messages in the background. This API should be developed with care obviously, since it also has great power.

At the minimum, this should be gated behind a permission. We could also consider providing the user with an option to allow/disallow add-ons from sending email regardless of if the permission was granted or not.

My use case is to create an add-on for weekly status updates, where I can gather them in a browserAction popup UI, and have a possibility to click send to send it to predefined recipients.

To convert my add-on Mail Merge to a WebExtension, an API to create and save or send messages is indeed needed. The API should cover both sending a message now or later and saving a message as a draft or template.

At the moment Mail Merge creates a new nsIMsgCompose object and interacts with nsIMsgCompose, nsIMsgComposeParams and nsIMsgCompFields. See: function mailmergeutils.compose() in /content/utils.js in Mail Merge 6.1.0.

When you develop such an API, please keep Mail Merge and its use-case in mind, thanks!

As sending emails in the background is indeed a sensitive operation with a (high) security impact, having a special permission for this in the manifest.json sounds reasonable.

I would also be fine, if the user had to confirm the actual delivery once per session. Obviously - in the case of Mail Merge - having the user to confirm the delivery of each individual message would kill the add-on from a usability perspective. (I have users, who send 100+, 1000+ and even 10000+ messages per session.)

I'm also trying to convert one of my extensions to a MailExtension and for me sending a mail is also needed:
The extension after a click on a button in the compose window sends the mail and saves it as .eml to the filesystem (archiving the mail into a Document Management System). Therefore the proposed send API command should also return an identifier of the just sent mail so that it would be possible to save this mail to the filesystem (by using messages.getRaw() and saving the content to a file).

@darktrogen @jorgk Are you able to advise if the "send API" is expected to land with Thunderbird 78 ESR? Thank you

I have no intention of working on this before 78.

Type: defect → enhancement

Would this be available in Thunderbird 78.x, i.e. 78.1 or 78.2? Or does this mean that the "send API" would be expected to land in the next ESR after 78? Thank you

I just don't know. My crystal ball can't see that far.

It might not happen at all. Such a thing has security implications we haven't even begun to tink through yet. (Do you want your Thunderbird used by a malicious extension as a vector for sending spam? Me neither.)

In the meantime for those of you converting existing code: as always, put it in an experiment API and use that. If you think it's generic enough to be used as a built-in API, show us what you've got and we'll consider it.

It might not happen at all. Such a thing has security implications we haven't even begun to think through yet. (Do you want your Thunderbird used by a malicious extension as a vector for sending spam? Me neither.)

  1. The Mail Merge add-on is not a malicious extension.
  2. You can currently Mail Merge with Thunderbird 68 ESR. Shouldn’t that mean that this is issue is not an enhancement but a bug?
  3. You can Mail Merge with Microsoft Outlook. There is a free Mail Merge program that works with Microsoft Outlook and is compatible with 2000, 2003, 2007, 2010, 2013, 2016 and 2019. Please let us know if you want a copy.
  4. Isn’t Thunderbird looking for more traction in the Enterprise space? Hence, is not implementing this issue a backwards step?
  5. Should this issue be brought up at Council Meetings and Status Meetings?

Thank you

I am not saying that Mail Merge or any other extension is malicious. I'm not saying anything about Mail Merge at all.

What I am saying is that having an API function to send email from an extension makes it very easy to create a malicious extension and makes Thunderbird a more attractive target for malicious people. We have to be careful about that.

And yes, I know that an extension could already send email in current and previous versions of Thunderbird. We are creating this for future versions of Thunderbird and we have the opportunity to decide how we want to do that. Doing it right first time is important, because change is hard.

You asked if this would be available in any particular version. I don't know. Currently I have a lot of work which is a higher priority than this bug. It will happen when it happens.

I don't want to escalate anything here. Obviously no pressure to implement this soon, but I want to second that this seems like a necessary API, and therefore a bug, not an enhancement.

One of the most attractive things about extendable software is the ability to automate things, and without that ability extensions are basically just complicated themes. With API functions like onBeforeSend(), a malicious extension can already intercept and modify email messages after you've stopped editing them. That seems equally dangerous, but of course the ability to filter messages is an important part of many extensions, and lacking that functionality would be unacceptable. I would argue the same is true for this.

@darktrogen I understand that you're not ixnaying the concept of a sending API, but I respectfully encourage you to change this back to 'bug' status, because WebExtensions would be fundamentally crippled if they don't support this feature if/when experiments are eventually no longer enabled.

Whether it's is a bug or an enhancement has no bearing on … anything, really. This is a request to add something that doesn't exist, so it's an enhancement.

Sorry for being a little bit off topic in this comment:

It is remarks like these in comment #6 and comment #8 that are so immensly frustrating and demotivating!!

I fully understand that classic / legacy restart extensions have no future. But I don't understand why you have to kill restartless extensions as well - I can see no valid technical reason for this decision. Converting Mail Merge to a restartless extension would have been possible without too much work.

Nevermind... The way into the future is obviousy WebExtensions: But Thunderbird is apparently lacking a lot of APIs with very valid use-cases - like this specific API to send messages.

We add-on developers are told that we can use a technique named WebExtensions Experiments for the time being. But again Thunderbird is lacking a clear commitment that WebExtensions Experiments will be there for years to come!

For my own add-on Mail Merge this means that I can spend the next few weeks or months trying to solve or workaround all the problems I probably face by converting my add-on to a WebExtensions Experiment. And - assuming that I somehow manage this successfully - maybe one year later Thunderbird decides to kill WebExtensions Experiments without all the necessary WebExtensions APIs in place, then all my hard work was wasted.

Again, sorry for being a little bit off topic in this comment, the next two comments will be on topic - I promise!

I also fully understand that an API to send messages will probably not make it into Thunderbird 78.

My basic understanding is, that at the moment the actual sending of the messages is tangled into the compose window. Therefore Mail Merge creates nsIMsgCompFields, nsIMsgComposeParams and nsIMsgCompose objects to setup all the necessary bits and peaces. See: function compose() in /content/utils.js in Mail Merge 6.1.0.

For the actual body of the message to work with embedded images it was necessary to make a little dance with the editor in the compose window. See function send() in /content/progress.js in Mail Merge 6.1.0.

I have heard that sending the messages will be rewritten in pure JavaScript in the future. So I think this rewrite would be a good time to also implement a WebExtension API to send messages.

Of course this also means that there must be a real commitment from Thunderbird to keep WebExtension Exeperiments alive until this rewrite including the WebExtension API to send messages have landed in Thunderbird.

Of course it is correct that an API to send messages has some imminent dangers, i.e. (1) information can be exfiltrated via emails and (2) the API can be used for spamming.

Both dangers are obviously not new to WebExtensions! Both dangers could have been achieved without much work with classic / legacy extensions as well. For more than 10 years the source code of my own add-on Mail Merge is released as free and open source software; Mail Merge clearly demonstrates how to send messages programmatically with "classic" techniques.

Exfiltrating information can obviously be done by other means as well: Think of an evil extension, that has access to the saved messages or the message being drafted in the compose window and has access to the internet. You can trivially read the contents of the messages and send them to a remote server. Yes, there are already all the necessary WebExtension APIs for this evil use-case in place!

Nevertheless a well designed API to send messages could mitigate both risks by (1) asking for a special permission at install time and (2) asking for another special permission at run time. See my own comment #1 as well.

(In reply to Alexander Bergmann from comment #13)

Both dangers are obviously not new to WebExtensions! Both dangers could have been achieved without much work with classic / legacy extensions as well. For more than 10 years the source code of my own add-on Mail Merge is released as free and open source software; Mail Merge clearly demonstrates how to send messages programmatically with "classic" techniques.

Classic/legacy extensions basically had no security/privacy model. I think moving to WebExtensions and creating a new dedicated API is an ideal time to reconsider those models, and Geoff is quite right to raise that.

WebExtensions have an improved permissions model, but there's still things to consider around APIs. For a possible example (without having thought about the implications, and let's not discuss at this stage because it might not even be on the table) maybe we should limit the send APIs to only be allowed to be called as a result of a user action rather than just randomly at any time.

(In reply to Alexander Bergmann from comment #12)

Of course this also means that there must be a real commitment from Thunderbird to keep WebExtension Exeperiments alive until this rewrite including the WebExtension API to send messages have landed in Thunderbird.

Whilst there's been no longer term commitment to keep Experiments alive, there also has been no discussion of a date to remove it except for that fact it might not be available for the long term. They certainly aren't going away in 78 - and so you can easily use similar functionality that you do today. I also think it would be rather silly if Thunderbird developers decided to remove experiments without considering the state of the current APIs/requests and getting feedback of add-on developers. So whilst I agree this is potentially an important API, I really don't see there is any discussion worth having here at the moment with respect to the api and the future of experiments.

I would also like to remind people that Thunderbird has very limited developers available, and lots of add-on developers are currently asking for various new APIs, fixes to APIs, or other things. Having been watching most of the bugs here, I have have to say I'm not seeing add-on developers try to help out by providing fixes to APIs or putting up patches for possible new APIs based on their own development of experimental APIs. That's been a little disappointing. (Disclaimer: Whilst I used to work on Thunderbird, I now work on Firefox, and my volunteer add-on development for Thunderbird is completely separate to my paid Firefox work). Note: if you want to discuss this further, I'd suggest doing so off-line not in this bug.

I think having an API to send would be useful, but agreed it needs a bit more thought, plus, the backend to support it needs a lot of work first.

Would a permission look something like the attached image? Thank you

Duplicate of this bug: 1654003
You need to log in before you can comment on or make changes to this bug.