Ich denke, dass ein Klick auf ein „E-Mail-Typ"-Feld, z. B. user_watching_first_post, Details zur von der beabsichtigten Empfängerin erhaltenen Rücksendemeldung anzeigen soll.
Auf meiner selbst gehosteten Website erhalte ich jedoch die oben genannte Fehlermeldung. Gibt es etwas, das ich tun kann, um das Problem zu beheben?
Danke.
Das ist korrekt. Ich habe das gerade auf meiner gehosteten Discourse-Website überprüft, und es funktioniert problemlos. Wenn deine Website die neueste Version von Discourse verwendet, frage ich mich, ob das Problem damit zusammenhängt, wie dein Mailserver die Rücksendemeldung weiterleitet.
Danke. Für den ausgehenden E-Mail-Verkehr verwende ich Mailgun. Ich glaube, ich habe die von Discourse empfohlenen Einstellungen verwendet.
Für den eingehenden E-Mail-Verkehr nutze ich diese Anleitung: Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver. Ich habe sie jedoch seit der Installation nie aktualisiert – könnte das das Problem sein? Da bei Discourse ./launcher rebuild app gilt, ist es dann ./launcher rebuild mail-receiver?
Ja, so funktioniert das Upgrade. Es ist eine Weile her seit dem letzten Update, denke ich, aber ein guter erster Schritt wäre, es und Discourse zu aktualisieren.
Ich habe beides aktualisiert und erhalte immer noch denselben Fehler, einschließlich (meiner Meinung nach) der E-Mails, die seit dem Upgrade eingegangen sind. Gibt es weitere Ideen?
Das gleiche Problem hier. Selbst gehostet, auf dem neuesten Stand. Rückläufer werden wie empfohlen behandelt. Links von vor der Umstellung auf die korrekte Rücklaufbehandlung funktionieren einwandfrei.
Ja, wahrscheinlich erhält Discourse die Meldung nicht von Mailgun. Ich weiß nicht genau, wie die Webhooks funktionieren, aber ich vermute, dass sie Discourse lediglich mitteilen, dass ein vorübergehender oder dauerhafter Fehler aufgetreten ist, ohne die Rücksendemeldung zu übermitteln.
Gibt es eine Möglichkeit, diese Discourse-Funktion mit Mailgun zu nutzen?
Es sollte möglich sein, zumindest den Fehlercode und die Fehlermeldung anzuzeigen:
Sowohl der SMTP-Fehlercode als auch die SMTP-Fehlermeldung werden beibehalten
“code”: 550,
“address”: “'baz@example.com”,
“error”: “Message was not accepted – invalid mailbox. Local mailbox 'baz@example.com is unavailable: user not found”
https://documentation.mailgun.com/en/latest/api-bounces.html#examples
Wenn nicht, brauchen wir zumindest eine sinnvolle Fehlermeldung, die erklärt, warum der Link nicht funktioniert 
Wurde hier bereits etwas unternommen? Ich wäre sehr dankbar, wenn ja
Ich verwende Digital Ocean und Mailgun (also die Hauptempfehlungen), daher stelle ich mir vor, dass ich nicht der Einzige mit dem Problem bin.
Nach meinen eigenen Tests scheint es in vielen Fällen, dass Bounces überhaupt nicht vom Mail-Empfänger empfangen werden. (Ich habe nur einen Verbindungsversuch gefunden, der sofort abgebrochen wurde). Ich sehe überhaupt keine Return-Path-Header gesetzt (sollte er das?), was mich vermuten lässt, dass sie meistens gar nicht zurückgesendet werden.
Hier gibt es ebenfalls noch ein Problem. Trotz meiner früheren Aussage scheinen nun keine dieser Links mehr zu funktionieren, und das bereits seit dem Start der Website. Anfangs schien es nur Bounces zu betreffen, die vor unserer korrekten Handhabung von Bounces auftraten (Configure VERP to handle bouncing e-mails).
Mir sind gerade jede Menge Warnungen im Fehlerprotok aufgefallen, die in diese Richtung gehen:
E-Mail kann nicht verarbeitet werden: Email::Receiver::AutoGeneratedEmailError
Empfangen: von ...
für <bounce+f7e463.5f70e9-...@forum.example.com>; ...
Betreff: Ihre Nachricht konnte nicht zugestellt werden
Vielleicht ist das der Grund, warum Discourse keine Details zu den zurückgewiesenen E-Mails hat.
Ich sehe diese Fehler nicht in den Protokollen, aber das Problem besteht weiterhin. Wenn ich auf den Wert „E-Mail-Typ“ für einen Eintrag in der Liste der zurückgesendeten E-Mails klicke, erhalte ich die Meldung „Ein Fehler ist aufgetreten: Discourse::NotFound“.
Es war bereits ausgewählt. Ich bin etwas weiter im Protokoll zurückgegangen und sehe zwar gelegentlich E-Mail-bezogene Meldungen, aber nicht die von Ihnen erwähnten.
Ich habe das gleiche Problem mit Mailgun. Anderer Host, also liegt es nicht daran!
Ich frage mich, ob es ein Problem mit den Mailgun-Konfigurationsanweisungen für die VERP-Einrichtung gibt:
Das ist schon eine Weile so, aber erst jetzt treten Probleme auf, da ich untersuchen möchte, warum ich derzeit so viele Bounces erhalte.
Das Problem scheint zu sein, dass in der Spalte Email Type keine Verknüpfung vorhanden ist und nichts hinter dem 
Symbol (rote Pfeile) ist:
Wenn ich darauf klicke, erhalte ich Folgendes:
Wenn ich mir den Seitenquelltext ansehe, scheinen den Anker-Tags im HTML der href komplett zu fehlen:
Ich habe VERP für Mailgun konfiguriert und es scheint ansonsten gut zu funktionieren.
Das ist das erwartete Verhalten, wenn die zurückgesendete Antwort nicht von Discourse verarbeitet wurde. Die Funktion funktioniert einwandfrei, wenn Discourse die Rücksendungen erhält, andernfalls wird diese Antwort für alle Rücksendungen angezeigt.
Können Sie dies bitte noch einmal überprüfen und den Test gemäß Configure VERP to handle bouncing e-mails durchführen?
Eine bessere Nachricht wäre in diesem Fall gut.
Ich glaube, Sie meinen, dass, wenn Discourse nur durch einen Mailgun-Webhook von dem Bounce erfährt, die Details des Bounces niemals an Discourse gesendet werden. Ist das richtig?
Wenn ja, gäbe es eine Möglichkeit, diese Details an Discourse zu senden und sie an derselben Stelle aufzuzeichnen und anzuzeigen wie Bounces, die von Discourse empfangen wurden? Ich denke, die Mailgun-API würde das zulassen ("Discourse::NotFound" error when click "Email Type" field on admin/email/bounced - #8 by Jonathan5).
Unter welchen Umständen würde Discourse Bounces bearbeiten und nicht der externe E-Mail-Dienst? (Ich weiß, dass Discourse E-Mails zurücksenden/ablehnen kann, aber ich meine die Bearbeitung von Bounce-Nachrichten, die von beabsichtigten E-Mail-Empfängern empfangen wurden.)
Einverstanden. Wenn etwas nicht wirklich kaputt ist, sollte es auch nicht kaputt aussehen. Discourse kann sicherlich eine beruhigendere Nachricht liefern.
