A discussion revolves around issues with Discourse’s reply key/email address validation when users reply to emails. ChrisBeach initially reports that a user’s email reply was rejected because the sender email address didn’t match the account email address.
Gerhard suggests enabling “Accept emails from anonymous users with no accounts” in the category settings, but ChrisBeach reveals that the issue is due to the user having two accounts on the forum.
Gerhard explains that email addresses are always validated, and disabling the “Only use reply key” setting isn’t a good idea. ChrisBeach argues that relying solely on the reply key for authorization would be sufficient, as email addresses can be spoofed.
Manuc shares a similar issue with a user having two accounts with different email addresses (@gmail.com and @googlemail.com). Zogstrip suggests adding the alternate domain email as a secondary email address on both accounts, but ChrisBeach points out that trusting the email address in the From header is a security issue.
Manuc attempts to add a secondary email address but encounters issues due to the emails already being taken. Zogstrip suggests merging the users, and Manuc considers this option.
Ultimately, ChrisBeach expresses frustration with the issue and wishes to disable the email address check, which is seen as fallible and unnecessary given the reply key validation.
I have set the following:
However, a user’s email reply was rejected as their sending email address didn’t match the account email address.
In this case I’d like their email reply to be accepted.
Is there anything I can change to ensure email replies are accepted in cases where the sender email address doesn’t match the account email address?
Make sure the enable_staged_users site setting is enabled.
For categories, enabling “Accept emails from anonymous users with no accounts” in the category’s settings should work.
Thanks @gerhard.
“Enable staged users” was in fact enabled already. In my case, the user has two accounts on the forum, both live. She replied to a notification from the “other” account and it got rejected by Discourse.
I’ve noticed also that the wording on the setting is a little ambiguous. “Only use reply key” suggests in my mind “don’t additionally validate email address” - but then the setting description says that disabling the setting allows user impersonation. I’ll try disabling the setting and see if that helps.
Was it a reply to a public topic or a group message? The exact error would be interesting too. You can find it in Admin → Emails → Rejected. The second account might not be allowed to reply to the topic.
The reply was to a public forum post
We’re sorry, but your email message to [“hitreply+[redacted]@se26.life”] (titled Re: SE26.life [Dining/Drinking] Zigghy Cafe [Now open]) didn’t work.
Disabling that setting isn’t a good idea.
Email addresses are always validated. Each reply key is bound to a topic and user. If they do not match, the email gets rejected. There’s only one exception. If the system knows that an email was forwarded to another user, because that other user was in the To or CC header of a previous reply, than it will allow that user to reply with the forwarded reply key.
In your case, the user needs to send with the correct email address. There’s no way around it. Most email clients should be smart enough to select the right sender address anyway.
Thanks for the explanation.
I would be comfortable with just the reply key being used to authorise the user.
After all, it’s easy to spoof an email address isn’t it?
Hi,
I have the same problem, a user has two accounts registered, one with her email as @googlemail.com and one as @gmail.com
The result is that sometimes her emails get rejected with the error:
Your reply was sent from a different email address than the one we expected, so we’re not sure if this is the same person.
I have a few other users replying by email and it only happens to this user, so I assume it’s the gmail/googlemail domain mismatch.
I am thinking of adding the alternate domain email as secondary email address on both accounts, or is there a better idea?
There are no other safe alternatives. Handling this automatically would definitely lead to security issues.
Isn’t it a security issue for Discourse to trust the email address in the From header, and to use this as part of its validation of incoming emails? I can set the From header to whatever I like.
That’s why we have reply keys 
Indeed! 
The reply key is what protects us from spoofed replies to notification emails. The email address listed in the From field doesn’t offer any real protection at all.
Forgive me for repeating the point, but including email address in the validation of replies is causing user-affecting usability issues and should be dropped IMO
Well I ventured into the Rails console (for the first time!) to add a secondary email address, but my workaround to add the @googlemail.com email to the @gmail.com account and viceversa didn’t work, because the emails have already been taken, of course it makes sense.
If anyone has other ideas to fix this reply by email issue, I’ll be grateful, as I generally am for being able to use Discourse.
You could merge the users (provided they’re the same user).
You’re right, I’ll look into that, cheers.
Could you let me know what you did to make this work please? I’m still having problems with Discourse rejecting legitimate post-by-emails from users. Very frustrating, trying to explain this issue to the users in question.
Ultimately I’d much prefer if I could just disable the check that Discourse performs on the email address of incoming mails (which is fallible to address spoofing and unnecessary, as the reply key is checked).
I don’t think I really solved it, but it’s been a while and my memory could be failing me.
I tried to add the secondary email address as explained here:
but that didn’t work because the email addresses were taken.
I think the solution would have been to merge the users, though I never proceeded with it because I just talked to the user and she has been using only one of the accounts since, so I can’t tell you how that would have worked in practice, sorry.
