Setting up a support inbox

Support

AI-generated summary

The discussion revolves around setting up a support inbox. jeffbyrnes wants to create a central mailbox for his organization using Discourse, similar to how Team Discourse handles emails. He is currently using Google Apps for emails and Mailgun for Discourse emails.

JammyDodger suggests using the mail-receiver to handle incoming emails, but Stephen points out that this solution only works for a single domain, and jeffbyrnes wants to use a mailbox at the root domain.

pfaffman proposes setting up the mail receiver on a different subdomain and then forwarding the mail from the main domain to the Discourse subdomain. jeffbyrnes tries to implement this solution but encounters issues with the Mailgun plugin.

After some troubleshooting, jeffbyrnes finds the solution:

  1. Set up a Mailgun Receiving Route for the address or RegEx pattern for receiving incoming email.
  2. Visit Google Admin and create a route that maps the address or pattern on the main domain to the Mailgun-powered subdomain.

This solution allows jeffbyrnes to set up a support inbox using Discourse and handle emails from the main domain.

1

Hey y’all, just came across this blog post How Does Team Discourse Use Discourse?, and this stuck out to me:

Anyone can email team@discourse.org and we handle those interactions in a central discourse mailbox, as private group messages.

How did y’all set that up? I would love to do this for steering@somervilleyimby.org (we currently use a Google Group & it’s pretty awkward). I use Google Apps for emails received by & sent from somervilleyimby.org, and Mailgun to handle Discourse emails (e.g., jeff@somervilleyimby.org; these are sent/received via discourse.somervilleyimby.org) so I’m a little unclear how I might set this up.

Any suggestions or perhaps a HOWTO? I spotted Configuring incoming email to create new topics or group messages, but that only gets me partway.

2

Hi ya. Did you see Discourse as a private email support portal

3

Ah nice nice! That’s a good read, but it doesn’t clarify the critical element I’m missing:

How do I get steering@somervilleyimby.org to end up at a Group in our Discourse?

Right now, the somervilleyimby.org domain is mapped to Google Apps email, and we have these two addresses:

Inbound & outbound email from our Discourse uses discourse.somervilleyimby.org via Mailgun, and is configured well.

But how would I map an email address on the main domain to be received by a Group inside Discourse?

I realize this is maybe outside the scope of Discourse itself, but figured someone might have an idea, and I suspect there are individual person@discourse.org addresses while also a shared team@discourse.org address that lands inside Team Discourse’s instance.

4

Would an email redirect to someaddress@discourse.somervilleyimby.org work?

5

I thought of that, still trying to piece together exactly how I’d wire that up though :thinking:

6

Hi Jeff :slightly_smiling_face:

I’m not 100% sure I’m following you right, but I use the mail-receiver on my self-hosted site to handle the incoming emails, and allow email-in in the admin settings, then set an email address in the group/category settings for where I want something to end up.

Does any of that sound helpful?

7

The problem with mail receiver though is that it handles a single domain.

Jeff currently uses a subdomain for the instance while wanting a mailbox at the root domain to also be handled.

8

So he’d need to set up the mail receiver on a different subdomain, and then forward the mail from the real one to the discourse one. (this should get split to its own topic)

9

Thanks everyone, and appreciate breaking this out to its own topic.

@JammyDodger that def. sounds like it would do the trick, and @pfaffman sounds like he’s right on the money with how I could handle my domain + subdomain setup.

If anyone is curious, the subdomain is what Mailgun suggests as best practice if you already have email on your domain handled by another entity (Google Apps, in our case).

tl;dr Email remains very hard.

10

So I figured out I can use Gmail routing rules to reroute email to steering@discourse.somervilleyimby.org, and Mailgun then POSTs that to my Mailgun plugin’s endpoint, /mailgun/incoming but they throw 422 Unprocessable Entity errors :thinking:

Guess I gotta dive in to the plugin code a bit…

11

If you’re not using mailgun to receive mail for your forum subdomain, I’d delete the mailgun MXs and use the Configure direct-delivery incoming email for self-hosted sites.

12

So I am using Mailgun for that, which clearly complicates this. But also don’t actually want to handle my own email b/c it’s just me handling admin.

Nonetheless y’all pointed me in the right direction!

13

/me sighs

Of course, this would all probably be less complicated if the upgrade to Discourse 3.x didn’t appear to break incoming email via the Mailgun plugin entirely :disappointed:

An error I’m seeing

From the logs:

# env tab
hostname	discourse-app
process_id	9406
application_version	3030a538192252c9d29e4fb763d31810327f370a
HTTP_HOST	discourse.somervilleyimby.org
REQUEST_URI	/mailgun/incoming
REQUEST_METHOD	POST
HTTP_USER_AGENT	Go-http-client/2.0
HTTP_ACCEPT	*/*
HTTP_X_FORWARDED_FOR	<redacted>
HTTP_X_REAL_IP	<redacted>
time	2:59 pm

# info
Message (27 copies reported)

ActionController::InvalidAuthenticityToken (Can't verify CSRF token authenticity.)
lib/middleware/omniauth_bypass_middleware.rb:74:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:366:in `call'
config/initializers/100-quiet_logger.rb:20:in `call'
config/initializers/100-silence_logger.rb:29:in `call'
lib/middleware/enforce_hostname.rb:24:in `call'
lib/middleware/request_tracker.rb:228:in `call'

Backtrace

actionpack (7.0.3.1) lib/action_controller/metal/request_forgery_protection.rb:251:in `handle_unverified_request'
actionpack (7.0.3.1) lib/action_controller/metal/request_forgery_protection.rb:284:in `handle_unverified_request'
actionpack (7.0.3.1) lib/action_controller/metal/request_forgery_protection.rb:273:in `verify_authenticity_token'
activesupport (7.0.3.1) lib/active_support/callbacks.rb:400:in `block in make_lambda'
activesupport (7.0.3.1) lib/active_support/callbacks.rb:199:in `block (2 levels) in halting'
actionpack (7.0.3.1) lib/abstract_controller/callbacks.rb:34:in `block (2 levels) in <module:Callbacks>'
activesupport (7.0.3.1) lib/active_support/callbacks.rb:200:in `block in halting'
activesupport (7.0.3.1) lib/active_support/callbacks.rb:595:in `block in invoke_before'
activesupport (7.0.3.1) lib/active_support/callbacks.rb:595:in `each'
activesupport (7.0.3.1) lib/active_support/callbacks.rb:595:in `invoke_before'

Env

HTTP HOSTS: discourse.somervilleyimby.org

# backtrace
Message (26 copies reported)

ActionController::InvalidAuthenticityToken (Can't verify CSRF token authenticity.)
lib/middleware/omniauth_bypass_middleware.rb:74:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:366:in `call'
config/initializers/100-quiet_logger.rb:20:in `call'
config/initializers/100-silence_logger.rb:29:in `call'
lib/middleware/enforce_hostname.rb:24:in `call'
lib/middleware/request_tracker.rb:228:in `call'

Backtrace

actionpack (7.0.3.1) lib/action_controller/metal/request_forgery_protection.rb:251:in `handle_unverified_request'
actionpack (7.0.3.1) lib/action_controller/metal/request_forgery_protection.rb:284:in `handle_unverified_request'
actionpack (7.0.3.1) lib/action_controller/metal/request_forgery_protection.rb:273:in `verify_authenticity_token'
activesupport (7.0.3.1) lib/active_support/callbacks.rb:400:in `block in make_lambda'
activesupport (7.0.3.1) lib/active_support/callbacks.rb:199:in `block (2 levels) in halting'
actionpack (7.0.3.1) lib/abstract_controller/callbacks.rb:34:in `block (2 levels) in <module:Callbacks>'
activesupport (7.0.3.1) lib/active_support/callbacks.rb:200:in `block in halting'
activesupport (7.0.3.1) lib/active_support/callbacks.rb:595:in `block in invoke_before'
activesupport (7.0.3.1) lib/active_support/callbacks.rb:595:in `each'
activesupport (7.0.3.1) lib/active_support/callbacks.rb:595:in `invoke_before'

Env

HTTP HOSTS: discourse.somervilleyimby.org

Gonna go see if there’s any other reports of similar, but if any of y’all have ideas I welcome them!

14

I got it! Ok, cool, so first, the upgrade to Discourse v3.x + my out of date Mailgun plugin got in the way.

Anyway, the HOW:

  1. Set up a Mailgun Receiving Route for the address or RegEx pattern for receiving incoming email
  2. Visit Google Admin
  3. On the left navigation, expand “Apps”, then “Google Workspace”, and click “Gmail” (this link might work?(
  4. Click Default routing
  5. Create a route that maps the address or pattern on your main domain to your Mailgun-powered subdomain:
    image
    image1340×2064 179 KB