Email can be properly posted if the incoming email has the appropriate message-ID as a “Reference” or “In-Reply-To” header. That’s going to cover most cases of replies even without wildcard email addresses.
1 Like
OK… But how do I actually go about setting it up? When setting up email reply it requires the email account name to have wildcards support. ${reply_key} is a necessary field in the account name.
Can I just put in a standard email address, and rely on the magic Reference/In-Reply-To headers?
OK. No worries. Got it working. 
reply by email address can take a normal email address without the reply_key. It will put the necessary headers into In-Reply-To.
However, for this to work, find related post with key must be turned off, with the potential security risk that the warning message states.
Probably a good idea to update the HOWTO docs, because I am quite sure last time I checked it still says reply_key is mandatory.
4 Likes
After playing around with the email in feature, I must admit that @codinghorror and @sam have a good point. This arrangement, though not the same as Create permission on categories, does have some unique advantages.
Advantages:
-
Anybody can mail in, instead of opening a user account. And the topics created are PM’s, restricted only to that staged user (and the users allowed into the category). This makes it uniquely suitable as a complaint/help/enquiry/ticketing system.
-
All conversations are turned back into emails for the originator, who doesn’t have a clue that he is dealing with a forum. As far as he’s concerned, we are replying to him via email.
-
If that staged user eventually becomes more trust-worthy, we can decide to invite him to become a real user. In that case, he can join the forum. Since we invite him in the first place, it is understood that he won’t be doing unreasonable things, so there is no more need for the
Createpermission which restricts posts to be seen only by the originator – those people are left as email-only correspondents. -
The PM’s can even be moved to different categories (provided that the destination category has
email inaddress set, otherwise emails won’t be sent out) for different groups of staff to handle depending on type of issue.
So, in other words, I find that the email in feature coupled with email reply very neatly solve the practical problem of running a public ticketing system. And a ticket-kind system is what the Create and Create/See permissions are most likely going to be used for.
8 Likes
Excellent so glad to hear it is working well for you! 
1 Like
Oops, just find out that email originators who are staged do not seem to get email replies. Only when they are approved then they get to receive email replies.
Is there a setting that will allow staged users to receive email replies?
Could be similar to: Email notifications of replies to staged users
I can see that for other people using this feature, staged users DO get email replies. Which is strange because for my forum, only approved users get emails. Once I approve a staged user, he/she starts getting email replies. Obviously this defeats the whole purpose of using staged account as a public ticketing system.
So you have mandatory new signup approval enabled on your site? Is that what you’re saying?
Yes, my forum is invite only, no public registration.
Is that the problem?
-
Turning off invite-only doesn’t seem to solve the issue…
-
Turning off login requirement doesn’t seem to solve the issue…
So, I am current at a loss why the reply emails don’t get sent.
OK! I finally solved the problem, but ended up having to trace the source code. 
In notification_emailer.rb:
def perform_enqueue(type, delay)
user = notification.user
return unless user.active? || user.staged?
return if SiteSetting.must_approve_users? && !user.approved?
return unless EMAILABLE_POST_TYPES.include?(post_type)
Jobs.enqueue_in(delay, :user_email, self.class.notification_params(notification, type))
end
The line:
return if SiteSetting.must_approve_users? && !user.approved?
is what’s throwing it off.
My forum has must_approve_users set, but staged users are obviously NOT approved… it would be rather strange for a user to be staged but then approved.
Therefore the whole thing falls apart if the forum is set to require approval.
I’m pretty sure the code should be:
return if SiteSetting.must_approve_users? && !user.staged? && !user.approved?
5 Likes
What is the current status on this? 2 years worth of threads without anything juicy at the bottom is a bit hard to catch up on 
This post sums up the main result in one paragraph:
1 Like
Ah, thanks.
Yea it’s 100% unusable like this in it’s current state. Would love to see it more obvious and usable, one day.
Give the email in feature a shot. It is not exactly the same, but it come close, and has a bunch of benefits.
3 Likes
It’s definitely not 100% unusable – I’m using it, and it works fine for me 
If it’s unusable for you: Can you elaborate? A detailed description of its problems, and suggestions for improvement, is a good start to getting this improved for everyone 
3 Likes
I’m interested in the Create/See permission in the following sense: I want a Topic where anyone can Create, BUT 1) only the OP and trusty TLXX users can Reply and 2) everyone can See it (which is why my request is totally different from PM’s).
- Create/Reply/See - TLX
- Create/See (+Reply to own) - Everyone
If this was treated above I missed it, and I’d be happy to be pointed at that content. Otherwise would love to hear any suggestions on this kind of mode. Thanks!
In the above case do created posts need to be approved first?
You can already effectively do this, by sending PMs to a group inbox. Those PMs can be converted back into topics in a category via the “Make Public Topic” option. From there you can use category permissions to grant a basic view right to all, but allows your higher TL users to respond.
1 Like
Thank you Stephen.
No, approval isn’t required. Sounds kind of annoying to have to do that for each post, but overlooking that, would this allow the original user to follow up even if they weren’t part of that group?
My use case is that I want to let untrusted users be able to ask questions and raise Topics but I want only my trusted users conversing with them.
No, there is no ‘reply to own’ permission. The OP wouldn’t be able to respond.
I think this is going to be your best workaround for now. If the mailbox is accessible to all staff recategorisation is only a few clicks.
3 Likes
I just ran into this one today – had to set up a Q&A-like category where users could post, but only a certain group of users can respond, and those do not necessarily have trust level 4 (i.e. they cannot post on locked topics, so I can’t auto-lock the topics to accomplish this functionality).
Turning group DMs into topics is undesirable for this case because of the manual clicks involved + I think the users in the group won’t have the permissions to do this themselves. (as mentioned above, they do not have tl4 / admin / etc)
The “Create/See” permission would be very helpful to have for this reason. The expected functionality of it would be that everyone with this permission can both post new topics and see existing topics, but cannot respond to any of them, including their own.
1 Like
That’s not a usual pattern for a community though, it might be useful for your case, particularly if you aren’t willing to use group inboxes, but for normal users that behaviour in a regular category is just confusing.
1 Like