User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

I would like to write a web extension version of Use BCC Instead C
https://addons.thunderbird.net/en-US/thunderbird/addon/use-bcc-instead-c/
(I didn't write this: I converted it for TB68 from the version no longer maintained by the original author.)

The addon's main function is to intercept 'send' and count the number of non-BCC recipients. It displays a message if it exceeds a parameter. It can also change recipients, e.g. from CC to BCC (and back).

So this is a request for an API that will allow me to do that.

The recipient(s) may include one or more mailing lists, of which it needs to count the addresses. That functionality is essential: a common case would be to CC a list rather than BCCing it. I think that the addressBooks and contacts API probably cover the detection of mailing lists, but I'm not sure.

(I would also be very happy if someone else wrote this addon - but I'm prepared to give it a go!)

I think there's a need for a "message about to be sent" event that extensions could listen to. I have at least one use case for it too.

This is going to be rather complicated to implement, especially with regard to getting the composed message to the extension and returning the modified message.

Off topic: Modifying message content during composition will be necessary for many add-ons, like Shrunked image resizer, QuickText, SmartTemplate and ThunderHTMLedit.

My requirenent seems similar to the addons mentioned here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1396172

Both concern checking recipients, preventing despatch with a user dialogue, and altering the recipients.

Sorry - wrong bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1532528

I would also like to modify a message prior to sending the message, as I need to encrypt parts of the message like Enigmail does. I suspect that Enigmail itself will also need this API once the authors start migrating from the legacy API.

This should block bug 1396172 ?
(I don't have a field to add that.)

It sounds a lot like bug 1532528 indeed. Would this be a duplicate of that bug, or are there things we'd need to do afterwards?

I think that the several requirements outlined in this bug /includes/ the requirement described in bug 1532528.

AAUI 1532528 is about blocking a message. This one is additionally about amending it (recipient types in my case) after the SEND button is pressed. Both envisage a dialogue and the user changing the message themselves and re-sendind it.

The Correct Identity add-on sets the identity of a message just as you start composing it, based on things like the identity that received the message you're replying to, or user-defined rules like "if any email address at example.com is in To, CC or BCC, set this message's identity so the From address shows my work email instead of my personal one". To implement that using MailExtensions, I think there needs to be an event that triggers while a new message is being created, and it must be able to see and modify header fields like To and From.

SingleDomain uses a MX experienmt to pick up on all the different ways emails are sent - both by keyboard and mouse. It pauses and either cancels or completes the sending = could this be turned into an function in the compose API?

I have similar requirement as Wouter. I need to modify the message (acessing and replacing body and attachments) after the Send button was clicked (or my own button was clicked).