A user (k4rtik) reported that a staged user (created from a forwarded email) received email notifications for replies in a private category topic, despite not being a group member — raising concerns about information leakage. maiki suggested checking group interaction settings or adjusting the ‘forwarded emails behaviour’ setting, noting this workflow is intentional for support use cases. Stephen clarified that the issue isn’t related to group permissions, since staged users are automatically granted access to topics they’re staged into — even in private categories — and are treated as part of the private message audience. k4rtik corrected that this was not a group PM but a topic in a private category. Stephen confirmed this is expected behavior, commonly used in support communities, and emphasized no data was leaked — just an unintended consequence of the settings. k4rtik asked how to prevent future emails to staged users, and Stephen advised against deleting the user (which wouldn’t prevent recurrence), instead recommending disabling email parsing, staged users, or training users to avoid forwarding emails unless they intend this outcome.
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.
