Here are the steps that happened in sequence that led me to discover this issue:
A user in a group forwarded an email to a private category (whose access is controlled by that group) from someone who is not on our discourse.
Because I have the “forwarded emails behaviour” setting set to “create replies”, a new topic was created automatically with OP by a new staged user (also created automatically) and a response post by the group member, both from the single email that the member sent.
Above steps are as expected, but this step is not: the staged user was sent a “user_replied” type email automatically with the contents of the reply post on the topic! This results in leak of information.
The staged user is not a member of the group and hence should not be sent emails from anything in the private category (even though they are owner of the topic/OP).
I think this is covered in the settings under your group at manage/interaction:
Posting
Who can @mention this group?
Who can message this group?
The workflow you described is intentional, and likely used more widely; we use it as a group inbox/support channel, which requires staged users (non-forum folks, like customers) to be able to email in to a private group used by internal support people.
If I were you I’d look at the forwarded emails behaviour setting. You maybe want “quote” or “hide”, depending on what your group is for.
I don’t think the group settings are a factor here. The email is created as a PM and the email settings have expanded the audience of the message to the group PLUS the staged user.
As the user is part of the PM audience they will receive emails related to that PM topic.
Groups are just one type of recipient for a private message. They aren’t a container or a boundary for it’s distribution.
Staged users don’t need permission to access a category, they will always have access to topics that they are staged into. If you forward an email into a category and the above settings are enabled they will behave like staged users within that topic.
This is how many discourse-based support communities work. They rely on this feature.
It’s working as intended, no information leaked you just weren’t aware of the implications of these settings.
If you delete the user you can anonymize their posts but that doesn’t stop a recurrence.
You can solve for the future by disabling the email parsing, disabling staged users, or educating your users not to do this unless they intend on the above outcome.
