Ein Support-Posteingang einrichten

[jeffbyrnes]

Hallo zusammen, ich bin gerade auf diesen Blogbeitrag gestoßen: How Does Team Discourse Use Discourse?, und das ist mir aufgefallen:

Jeder kann eine E-Mail an team@discourse.org senden, und wir bearbeiten diese Interaktionen in einem zentralen Discourse-Posteingang als private Gruppennachrichten.

Wie habt ihr das eingerichtet? Ich würde das gerne für steering@somervilleyimby.org machen (wir verwenden derzeit eine Google-Gruppe, und das ist ziemlich umständlich). Ich benutze Google Apps für E-Mails, die von somervilleyimby.org empfangen und gesendet werden, und Mailgun, um Discourse-E-Mails zu verarbeiten (z. B. jeff@somervilleyimby.org; diese werden über discourse.somervilleyimby.org gesendet/empfangen), daher bin ich mir nicht ganz sicher, wie ich das einrichten könnte.

Irgendwelche Vorschläge oder vielleicht eine Anleitung (HOWTO)? Ich habe Configuring incoming email to create new topics or group messages gesehen, aber das bringt mich nur teilweise weiter.

[HAWK]

Hallo. Hast du Discourse as a private email support portal gesehen?

[jeffbyrnes]

Ah, schön, schön! Das ist eine gute Lektüre, aber sie klärt nicht das kritische Element, das mir fehlt:

Wie bekomme ich steering@somervilleyimby.org dazu, in unserem Discourse in einer Gruppe zu landen?

Derzeit ist die Domain somervilleyimby.org Google Apps E-Mail zugeordnet, und wir haben diese beiden Adressen:

• jeff@somervilleyimby.org (meine Adresse)
• steering@somervilleyimby.org (Google Groups Adresse)

Eingehende und ausgehende E-Mails von unserem Discourse verwenden discourse.somervilleyimby.org über Mailgun und sind gut konfiguriert.

Aber wie würde ich eine E-Mail-Adresse auf der Hauptdomain zuordnen, damit sie von einer Gruppe innerhalb von Discourse empfangen wird?

Mir ist bewusst, dass dies vielleicht außerhalb des Geltungsbereichs von Discourse selbst liegt, aber ich dachte, jemand hätte vielleicht eine Idee, und ich vermute, dass es einzelne person@discourse.org-Adressen gibt, während es auch eine gemeinsame team@discourse.org-Adresse gibt, die in der Instanz von Team Discourse landet.

[hosch (Holger Schmermbeck)]

Würde eine E-Mail-Umleitung an someaddress@discourse.somervilleyimby.org funktionieren?

[jeffbyrnes]

Das habe ich auch gedacht, versuche aber immer noch zusammenzufügen, wie ich das verdrahten würde :denkend:

[JammyDodger]

Hallo Jeff

Ich bin mir nicht ganz sicher, ob ich dir richtig folge, aber ich benutze den Mail-Empfänger auf meiner selbst gehosteten Seite, um eingehende E-Mails zu verarbeiten, und erlaube E-Mail-Eingang in den Admin-Einstellungen. Dann lege ich eine E-Mail-Adresse in den Gruppen-/Kategorieeinstellungen fest, wohin ich etwas haben möchte.

Klingt davon irgendetwas hilfreich?

[Stephen]

Das Problem mit Mail Receiver ist jedoch, dass er eine einzelne Domain verarbeitet.

Jeff verwendet derzeit eine Subdomain für die Instanz, möchte aber auch ein Postfach unter der Root-Domain verwalten lassen.

[pfaffman (Jay Pfaffman)]

Er müsste also den Mail-Empfänger auf einer anderen Subdomain einrichten und dann die E-Mails von der echten an die Discourse-Domain weiterleiten. (dies sollte in ein eigenes Thema aufgeteilt werden)

[jeffbyrnes]

Vielen Dank an alle, und ich weiß es zu schätzen, dass dies zu einem eigenen Thema gemacht wurde.

@JammyDodger, das klingt definitiv nach der Lösung, und @pfaffman scheint genau richtig zu liegen, wie ich meine Domain- und Subdomain-Einrichtung handhaben könnte.

Falls es jemanden interessiert: Die Subdomain ist das, was Mailgun als Best Practice vorschlägt, wenn Sie bereits E-Mails auf Ihrer Domain von einem anderen Anbieter (in unserem Fall Google Apps) verwalten lassen.

#Kurz gesagt: E-Mail bleibt sehr schwierig.

[jeffbyrnes]

Ich habe herausgefunden, dass ich Gmail-Weiterleitungsregeln verwenden kann, um E-Mails an steering@discourse.somervilleyimby.org weiterzuleiten, und Mailgun POSTet diese dann an den Endpunkt meines Mailgun-Plugins, /mailgun/incoming, aber sie werfen 422 Unprocessable Entity-Fehler

Ich muss wohl ein wenig in den Plugin-Code eintauchen…

[pfaffman (Jay Pfaffman)]

Wenn Sie Mailgun nicht zum Empfangen von E-Mails für Ihre Foren-Subdomain verwenden, sollten Sie die Mailgun-MX-Einträge löschen und die Konfiguration der direkten Zustellung eingehender E-Mails für selbst gehostete Websites verwenden.

[jeffbyrnes]

Ich benutze dafür Mailgun, was das Ganze eindeutig verkompliziert. Aber ich möchte meine E-Mails auch nicht selbst verwalten, da ich die Administration alleine mache.

Nichtsdestotrotz habt ihr mich in die richtige Richtung gewiesen!

[jeffbyrnes]

/me seufzt

Natürlich wäre das alles wahrscheinlich weniger kompliziert, wenn das Upgrade auf Discourse 3.x den eingehenden E-Mail-Verkehr über das Mailgun-Plugin komplett zu brechen scheint

Ein Fehler, den ich sehe

Aus den Protokollen:

# 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

Ich werde nachsehen, ob es noch andere Berichte über ähnliche Probleme gibt, aber wenn jemand von euch Ideen hat, bin ich dankbar!

[jeffbyrnes]

Verstanden! Okay, cool, also zuerst, das Upgrade auf Discourse v3.x + mein veraltetes Mailgun-Plugin kamen dazwischen.

Wie auch immer, die Vorgehensweise:

1. Richten Sie eine Mailgun-Empfangsroute für die Adresse oder das RegEx-Muster für den Empfang eingehender E-Mails ein.
2. Besuchen Sie Google Admin.
3. Erweitern Sie in der linken Navigation „Apps“, dann „Google Workspace“ und klicken Sie auf „Gmail“ (dieser Link funktioniert möglicherweise?).
4. Klicken Sie auf Standard-Routing.
5. Erstellen Sie eine Route, die die Adresse oder das Muster auf Ihrer Hauptdomain Ihrer Mailgun-gestützten Subdomain zuordnet: