As recommended by @mpalmer, here’s a bug report for a phenomenon that caused some confusion for me:
How to reproduce:
- Produce a messaging topic T that is inaccessible to user A, but deliver a mail from that topic to this user without Discourse knowing, e.g. by replying to the topic via mail and CCing a mailing list containing user A. (See here for a description of a real-world occurrence of this.)
- As user A, reply to this message, addressing it to the group inbox address of group G. Use a mail client that adds an
In-Reply-To header to do this.
Discourse creates a new message between group G and user A. (It may try to post a reply in topic T instead because it sees the
In-Reply-To header, but falls back to the new message because user A lacks permissions for a reply.)
Discourse sees the
In-Reply-To header and tries to post a reply from user A in topic T. Because A lacks permissions to do so, Discourse sends him an email explaining that the topic was probably closed or deleted, and does not deliver that message.
It seems an easier option to first improve the error message to indicate that the user does not have a) an account on the site or b) access to the topic.
That’s way easier for sure, but it wouldn’t help me. Remember that users sending emails to group inboxes may not be tech savvy, and may have no idea what this “Discourse” thing that’s sending them emails actually is.
I love Discourse’s incoming mail support because we as a team can use it to organize our communication with the outside, but I need to rely on incoming mails being actually received, versus generating error messages that will puzzle outsiders.
Proper error messages is the first step though.
As long as it is the first of two steps, I agree
I just had another occurrence of this, but this time, the mail was addressed to a reply address.
In that case, I think the correct solution is to let the user post there (and add him to the message). Wo know that the reply tokens are a secure, random secret, so possession of the token proves that an email from the thread was forwarded to the sending user.
@zogstrip can you add this to your list? A bad error message should always have priority. Good, clear error messages are essential to everyone’s sanity.
Any movement on this @zogstrip?
@maja can you add to your list to ensure we have a proper error message here?