By default Discourse needs to reply to a special email address that contains a reply key. The reply key is generated when Discourse sends you a notification about a new post and it is only valid for you 1) and that specific post. That’s how Discourse verifies that you are who you claim to be (because nobody else should have access to that reply key) and it also knows to which post you are replying.
Such an email address looks like this: support+148425ef5b96ce547e9d79fb3b605760@example.com
Without a reply key, Discourse assumes that you want to create a new topic.
But, there is a site setting which allows you to change that behaviour. Discourse will try to find related posts by Message-ID when you disable find_related_post_with_key in the settings.
There is a reason why that setting is enabled by default. Disabling it makes incoming emails a little bit less secure.
I’d say this is neither a bug nor a feature request
1) There is one exception to that rule. When you reply to Discourse using a reply key and include other users via To or CC, Discourse knows about that and allows incoming emails using the same reply key from those users.
Aha, so there is a setting, interesting. I see it says “WARNING: disabling this allows user impersonation based on email address” - how does this happen? Presumably it’s some kind of header shenanigans?
Right, I’m aware of spoofing the From header, but I feel I’m still missing a piece of the puzzle so apologies if I’m dragging this out. How does the use of a dedicated To address (reply+token@myinstance) help detect / block From header forgery? Or to put it another way, how does checking the message-id enable that vector?
It doesn’t prevent spoofing of the From header. But the reply key is like a secret that is only known by Discourse and you.
Every email sent by Discourse uses a different key. So, unless someone gains access to your emails or you forward the key to someone, nobody should be able to send an email to Discourse and successfully pretend to be you.