With OpenPGP enabled, the following test fails:
comm/mail/components/extensions/test/browser/browser_ext_compose_begin.js

The failing test opens a composer window and sets a mailing list from the user's address book as the recipient.

Today's behavior is, the name of the mailing list is shown as the recipient.

With OpenPGP enabled, we instead get all the individual recipients.

I haven't found where the Enigmail does that replacement, but it seems reasonable to me. When using encrypted email, we need to check keys for individual recipients. Also, we want to give the user individual feedback for each recipient, which is more difficult if the real recipients are hidden behind a list identifier.

We need to find an agreement how to solve this scenario.

The simpler solution is to use Enigmail's behavior, replace with the individual recipients, and adjust the test. This could also change user expectations. If the user changes the mailing lists members after having started to compose the list, those changes to the address book list would get ignored for the current message.

The alternative is to keep the existing TB behavior, keep showing the list identifier as the recipient. With this approach, we'll need additional UI to display an overall key status for the list, and view the details of the key status for the list members.

Thoughts?

additional test that's affected:
comm/mail/components/extensions/test/browser/browser_ext_compose_onBeforeSend.js

Patrick, is my guess correct, that the Enigmail code does that replacement? Do you remember where I can find that code?

Magnus, do you have thoughts which strategy we should prefer? The replacement strategy might be less work.

(In reply to Kai Engert (:KaiE:) from comment #2)

Patrick, is my guess correct, that the Enigmail code does that replacement? Do you remember where I can find that code?

Yes, see here:
https://gitlab.com/enigmail/enigmail/-/blob/master/ui/content/enigmailMsgComposeOverlay.js#L2259

Expanding the lists always in the compose window seems it should be ok generally, especially now with the new pills so you can get a better overview of who you're sending to. We might just want to drop the concept of having mail lists ever showing in the UI and just use them as shortcuts to enter many addresses. Bug 119977. Aleca, WDYT?

Mh, this indeed needs further discussion to find a general approach that covers all possible scenarios and doesn't break user expectations.

I was thinking about showing all the contacts from a mailing in the addressing row, but that introduces some issues that I'd like to avoid.
Things like:

• If a mailing list has 100+ addresses, do you really need to see them all all the times? That might look/feel very disruptive.
• If a user has a draft message where he added a mailing list, and updates the mailing list from the Address Book, that message won't reflect the changes to the mailing list.

A sort of half baked idea I was exploring was to return an "hybrid" pill when adding a mailing list.
The pill would show the mailing list as usual, but it would also allow to expand the content and see all the addresses.
In this view, the user will be able to view all the recipients, and in case he decides to delete or edit some, we can "explode" the list and convert all the addresses into pills, and prompt the user to let him know that these changes won't affect the mailing list in the Address Book.

As Kai pointed out, with this approach we will need some new UI implementation to handle the key status of the list, and maybe some further UI updates to show the status of each address when a list is expanded.

What do you guys think?

I'm not sure those are real, important use cases that people would care much about. Would tend to think no. It's likely lists are usually fairly small just because it doesn't scale well. If you go above say 15 people, you need a real mailing list.

I notice the current enigmail code doesn't expand the alias in all scenarios.

If you use the addressbook to select a list and click the "write" button, then the list is expanded. That's the same scenario the automated test uses.

However, if you manually type the list alias into a recipient field, then the list alias is preserved. Even when clicking send, the list alias is kept.

This patch changes the test to expect the expanded recipient list.

I tried to parameterize the code based on build time flag MailConstants.MOZ_OPENPGP but I couldn't find a way to parameterize the inner code block that is loaded as the test extension.

Because of bug 1625574, we could enable the openpgp code by default in comm-central, even if the RNP libraries (bug 1518166) are not available yet.

However, if RNP libs are unavailable at runtime, the openpgp code to trigger the mailing list won't be reached.

This means, this modified test code will work if RNP is available, and fail if RNP is unavailable.

Because this test code is part of a simulation of extension code, I'm not aware of any way to check if RNP is available, from inside that extension test code. (I guess that code is limited to official extension APIs.)

Consequently, I think we should expand the mailing lists at composer open time. With that change, the test will always find the expanded list, whether openpgp code is active or inactive.

Geoff, opinion on dropping mail lists from ever showing as such in compose?

I agree with Aleca. I think we need some sort of half-way-between UI that can display all the list members but still handle them as a group. Consider the situation of mistakenly adding a list to the recipients then wanting to remove it (which is admittedly rare but I would find it very irritating).

Working on the improved UI probably isn't simple and will take some time to get done.

I'd like to use a short term workaround, and will simply remove the call to expand inside the openpgp code.
This is also sufficient to make the tests work (no changes to tests necessary).

Patrick, I wonder what the purpose of gMsgCompose.expandMailingLists() is, because apparently, even when NOT expanding, the code will correctly look for keys of the list members.

I can take care of the UI/UX of it after this implementation lands, so I'll have the full working OpenPGP code for mailing lists.

Magnus, attached patch is a precondition to enable OpenPGP in nightly. Could you please r+?

Setting keyword leave-open to prevent auto-closing when landing the temporary fix.

Is this bug a match to this facebook comment? "In older versions such as 68, receiver lists can be encrypted. However, with the newer encryption technique of Thunderbird, receiver lists cannot be used for encryption anymore as a key has to exist for each recipient. Is it planned to bring back encryption for receiver lists? This would be really great and also important for our work."

(In reply to Wayne Mery (:wsmwk) from comment #18)

Is this bug a match to this facebook comment? "In older versions such as 68, receiver lists can be encrypted. However, with the newer encryption technique of Thunderbird, receiver lists cannot be used for encryption anymore as a key has to exist for each recipient.

Yes, looks it is.

Wayne, I believe we had discussed this a while ago.

The comment you have forwarded isn't allowing me to understand how the user expects the scenario to work.
I believe I had asked that the user gets in contact with me directly, so I can get answers to my questions, but I believe this never happened.

This is still the situation. The above comment doesn't make it clear what the user wants to happen.

Which of the following describes what the user wants:

(1) Does the user expect that the address book list is expanded into the TO/CC field of the composer window, and will the user ensure that matching and accepted public keys are available for each email address the is part of the list?

Or, alternative expectation:

(2) Does the user expect that Thunderbird keeps the list name in the TO/CC field? Does the user expect to be able to define/select a single OpenPGP public key for encrypting the message to that list of recipients? If this is the answer, then I'd appreciate an additional explanation from the user: How do you ensure, in your environment, that all recipients can decrypt the message, that is encrypted only to a single public key?

I'm making assumptions here. My assumptions might not match what the user expects, meaning, neither (1) nor (2) describe what the user wants.

I really need to interact with the user(s) asking these questions.

Christian, do you think clarification of comment 18 needed to resolve comment 21? Or do you have your own opinion?

Better late than never:
I believe comment #18 refers in general terms to the fact, that with TB68/Enigmail encrypted mailing lists could be used based on Enigmail per-recipient rules.
With TB78 email group encryption was not possible initially. That has later been rectified by the introduction of the OpenPGP alias functionality (thanks again for that).

Wrt comment #21, I'd say the problem of expanding a mailing list and to ensure that matching and accepted public keys are available for each email address that is part of the list has been addressed by now with the Key Assistant. I'd not expect that the mailing list is expanded into the TO/CC field of the composer window, and it isn't done today either.

So I'm not sure what problem this bug is still trying to resolve. May be it should just be closed?