User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.85 Safari/537.36

Steps to reproduce:

Bug 271405 describes Warning before sending an Email with more than a preset number of visible Addresses.
Thomas: Bug 271405 Comment #85 introduced the need to 'enforce the threshold'.

Actual results:

For our type of social organization with Groups in most countries, Anonymity and Privacy are a vital part of our Traditions.
Consequently, we must not reveal name or contact information.
Typically a single archival address is placed in the To: field, and names from an Address List are all placed into Bcc:.
Human error might accidentally: Place those names into To: or Cc:, Then override the Bug 271405 Warning.

Expected results:

An enforced limit should completely prevent the Sending of any email with more than the preset limit of visible addresses. (i.e. when the Number of non-Bcc: > Set Limit).

Thanks Roger, this looks like an essential feature for anyone involved in bulk communications, because sharing large amount of private addresses with large groups will typically violate the privacy of the recipients, which may have real-life impact and relevance (think of groups where privacy may matter even more, democracy activists, patients groups, Anonymous Alcoholics etc.).
Also, companies will not want to compromise the privacy of their clients, business partners etc. in their bulk communications (-> Blocks: tb-enterprise).
Having an option to enforce the threshold (as proposed by this bug) will be crucial for all those scenarios.

Bug 271405 Comment 81 mentions that around 800 users were using respective addons around this feature.

Not sure we'd want a forced prevention per se. I think this should behave similarly to the attachment reminder aggressive pref: if you set it to aggressive, if you have too many public recipient you will have to click through an confirmation dialog.

Let's morph this bug to do that: if the aggressive pref is set, the user would have to click ok to a confirmation before sending, if the number of users is high. Similar to compose.attachment_reminder_aggressive

Could it be implemented in such a way that a future addon could detect the the confirmation and actually /prevent/ sending. For example by adding a flag to the ComposeDetails returned by onBeforeSend - 'aggressive non-BCC recipient limit exceeded/overridden'.

A very simple add-on could then meet the requirement in the OP without re-counting the recipients.

Well, if the use case is to never allow to send to anyone in To/Cc, an add-on should always just do that. It doesn't really need the pref or anything else.

The use case is to never allow the user to /exceed the limit/.

For example to prevent a business, club, or similar organisation CC-ing a mailing-list of customers or members and then accidentally clicking through the warning, while allowing administrative or business emails that address just a few people.

It's a facility that the old Use BCC Instead and my Limit non-BCC Recipients add-ons provide. Bug 271405, bug 1705100, plus this putative add-on would provide all the functionality of those add-ons, which collectively had 800 users last time I counted (though how many enable this option I don't know).

For the use-case of this enhancement, it is not useful when there has to be a pref, when a dialog is shown, or when an add-on has to be installed.
What is needed is a default maximum visible recipients of like 10 or 20, with a hard prevention of sending mail above that limit, or at most with a dialog that proposes to convert the recipients to BCC and then send (or to not send at all and go back to composition to fix the error manually).
At most there could be a hidden pref where that hard limit could be configured (accessible to those that make the effort to google the name of the pref).

The result of the enhancement should be that those that installed Thunderbird with default settings, and are not aware of the problem are unable to send those messages. Presenting an "are you sure" dialog where an OK answer still sends the message is not going to solve the issue, because the issue only arises with users that are unaware of the issue, or are in a hurry.

Thanks Rob; You have well summarized the need.
Our operational concerns center around "in a hurry" Privacy mistakes.
We need a 'hard limit'. In our case, Limit To:+Cc: = 2
Because we may have more than one IMAP user of the Email account, we want an implementation which can be simply described to a non-specialist.
The Limit non-BCC Add-on is one such method; we tell the users what to install and what value to set (then we have them attempt to 'send' to a test Address list).
FYI: We re-run the same test after every T'bird update.
Setting the limit by a Preference parameter would achieve the same end; but is perhaps harder to explain to the non-specialist.
A 'hidden' pref would be more resistant to tampering but harder to audit visually.
For our users, the present hard limit is very reassuring.

Roger: you are in the position that you already are aware of the problem and are doing procedures to resolve it.
In that case you will probably be able to change a pref, or maybe do a setting in the GUI.
My point is that we should protect those that aren't even aware that there is a problem, and just install the program with default settings and no add-on.
When Thunderbird by default prevents those issues, maybe even Outlook would get the same enhancement. And we see less of those GDPR violations.

Rob: You raise a very valid question which is within the scope of the Topic: Should an Email Client 'Encourage' or 'Enforce' good practice.
I often remind clients: "There is no free Email service, your connections and your content provide value to the hosting provider.
Personally, I support raising awareness of GDPR, CCPA, and other subsequent related regulations.
I don't like the idea the user would suddenly hit a preset hidden limit - perhaps when they are in a hurry.
Also I fear implementation disagreement to set a 'standard' T'Bird limit!
T'Bird might have one limit for all its email accounts, or a per account limit.
My preference: the procedure for adding an Email account prompt/explain why the Visible address limit helps to achieve the goals of GDPR etc. It could suggest: 'lower limit helps privacy'.
I have in mind a dialog box with radio buttons for 2, 5, 10, or Custom, Visible Limit.
Later if the user hits the limit when Sending, they would not be surprised.
I don't favor then immediately showing the limit-setting dialog in a way which would encourage the user to simply pick a higher number; better tell the user the non-Bcc: Addressee limit is in the account settings?
(BTW: Most users don't understand Bcc:, perhaps better to use a feature name which refers to visible addresses?)

I don't want to expand the scope to topics like "they are looking in your emails"!
The only reason for wanting this change is that every week there is some news item that says "company or healthcare facility X has mistakenly sent a message to a large group of clients with all addresses in the To or CC and now everyone knows who else is in that group".
These mistakes happen so often that it would be good to prevent them.
Now, of course in most of the cases the mail is sent using Microsoft Outlook.
But, when Thunderbird would set a good example, and the message that "it is a fault of the e-mail client and see, Thunderbird has already fixed it!" would go around, we could hope that other clients including Outlook would also be fixed.
But of course it is only going to work when it is a default setting, and when there is no "OK to send this mail to 1000 recipients" popup that people click away without thinking.
This concludes my contribution to this bug, I am not interested in longwinding "but this, but that" elaborations, only in the fix for the problem.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/43dedc6168a2
Add pref for aggressive too many public recipients warning. r=mkmelin