'Per E-Mail antworten' funktioniert nach der Migration nicht mehr

Unterstützung
1

Hallo,

wir haben unsere selbstgehostete Discourse-Instanz gerade von einem Server auf einen anderen migriert. Alle Einstellungen wurden vom alten auf das neue System übertragen, einschließlich „Antwort per E-Mail“ und „Neue Beiträge per E-Mail zulassen“. Für den E-Mail-Teil nutzen wir das discourse/mail-receiver-Setup.

Sowohl die „Antwort-an“-Funktion als auch die „Neue E-Mail“-Funktion haben im alten System einwandfrei funktioniert, doch auf dem neuen Server gibt es ein Problem: Die „Antwort-an“-Funktion funktioniert nicht mehr.

  1. Als unbekannter Nutzer sende ich eine E-Mail an die dafür konfigurierte Adresse. Ich sehe, dass die E-Mail eintrifft. Ein neuer gestaffelter Nutzer wird erstellt. Die Nachricht wird veröffentlicht. Super!
  2. Als Team-Nutzer kann ich auf diese Nachricht antworten, und die Nachricht wird korrekt zugestellt. Toll!
  3. ABER beim erneuten Antworten auf diese E-Mail, was eigentlich zu einer Antwort in Discourse führen sollte, schlägt das fehl. Wenn die Nachricht bei mail-receiver eintrifft, versucht sie, sie über die API zu übermitteln, was jedoch mit folgenden Log-Fehlern scheitert.

(Aus Datenschutzgründen habe ich Benutzer- und Domainnamen geändert.)

<22>Sep 13 09:45:15 postfix/qmgr[81]: AF8665CA560: from=<test-user@outside-org.nl>, size=9233, nrcpt=1 (queue active)
<23>Sep 13 09:45:15 receive-mail[144]: Recipient: 6ffb2772c3b09bf60fc2705753fb32ce@forum.acme.org
<19>Sep 13 09:45:15 receive-mail[144]: Failed to POST the e-mail to https://forum.acme.org/admin/email/handle_mail: 400
<22>Sep 13 09:45:15 postfix/pipe[143]: AF8665CA560: to=<6ffb2772c3b09bf60fc2705753fb32ce@forum.acme.org>, relay=discourse, delay=1126, delays=1126/0.01/0/0.21, dsn=4.3.0, status=deferred (temporary failure)

Wie gesagt, dieser gesamte Wechselverkehr hat im alten Setup einwandfrei funktioniert. Das neue Setup ist exakt dasselbe wie das alte (local_discourse/app und local_discourse/mail-receiver).

  • Kann mir jemand sagen, warum die handle_mail-API bei einer Antwort-E-Mail einen 400-Fehler wirft?
  • Wäre es möglich, die Protokollierung detaillierter zu gestalten, damit ich tiefer graben kann?
2

Du solltest weitere Informationen unter Admin - E-Mails - Abgelehnt finden.

3

Nein, leider wird es nicht einmal als „Abgelehnt" angezeigt. Ich vermute, das liegt daran, dass es auf einen 400 Bad Request stößt.

4

Ich frage mich, was der Unterschied zwischen „neue E-Mail" und „Antwort-E-Mail" ist. Ich würde sagen, der einzige relevante Unterschied ist der Empfänger. Beide werden jedoch vom selben Handler (mail-receiver) verarbeitet und an dieselbe API gesendet: https://forum.acme.org/admin/email/handle_mail

5

Hast du das auch migriert? Hast du die MX-Einträge entsprechend aktualisiert?

Hast du den Hostnamen deines Forums geändert?

6
  • Der Mail-Empfänger wurde ebenfalls migriert.
  • Die Hostnamen bleiben unverändert.

Das Problem liegt nicht im MX-Teil. Die E-Mail kommt laut den Logs beim Mail-Empfänger an, wird jedoch sofort nach der Übermittlung an die API mit einem 400-Fehler (was einen fehlerhaften Request bedeutet) beantwortet.

7

Es gibt jedoch einen Unterschied im Setup: Ich habe einen Reverse-Proxy (nginx) davor geschaltet, um die Funktion „vorübergehend offline" zu ermöglichen und möglicherweise weitere Websites auf demselben Host unterzubringen. Trotzdem verstehe ich nicht, warum dies ein Problem sein sollte, da neue Themen problemlos angenommen werden. Dennoch werde ich testen, was passiert, wenn ich den Reverse-Proxy aus der Gleichung entferne…

Update
Schade! Ich habe die Discourse-Installation hinter dem nginx-Reverse-Proxy verschoben (im Wesentlichen habe ich app mit den korrekten Einstellungen neu aufgebaut und nginx heruntergefahren), aber das hat das Problem überhaupt nicht behoben!
Jetzt bin ich wirklich ratlos. Was ist hier los?

Zusammenfassung:

  • Unsere vorherige Discourse-Installation (app und Mail-Empfänger) konnte neue Themen und Antworten annehmen.
  • Nach der Migration auf einen neuen Server (alles identisch) werden neue Themen weiterhin angenommen, aber Antworten werden mit einem 400 Bad Request abgewiesen.
8

Ich habe das Problem gefunden, das diese Situation verursacht.
Beim Testen mit verschiedenen E-Mail-Clients stellte ich fest, dass E-Mails, die mit meinem Desktop-Client (Thunderbird) gesendet wurden, den Fehler „400 Bad Request" auslösten, während die Antwort über den Webclient erfolgreich ankam.

Bei weiterer Untersuchung stellte ich fest, dass Thunderbird beim Antworten somehow auf die Western (Windows-1252)-Kodierung umstellte, während der Webclient bei UTF-8 blieb. Nachdem ich Thunderbird gezwungen hatte, UTF-8 zu verwenden, kam die E-Mail ebenfalls an.

Thunderbird, E-Mail wurde nicht zugestellt

Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Webmail

Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Thunderbird, E-Mail wurde zugestellt

Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Ich würde sagen, dass der E-Mail-Empfänger eine Kodierungsprüfung und -bereinigung durchführen sollte, aber da ich kein Ruby-Entwickler bin, überlasse ich diesen Teil des Codes den Entwicklern :smiley: