Es scheint viele seltsame Fälle zu geben, in denen E-Mails eigentlich nicht abgelehnt werden sollten, aber dennoch abgelehnt werden. Das bedeutet, dass wir manchmal Support-E-Mails von Nutzern nie erhalten.
So werden beispielsweise E-Mails, die von mac.com-Adressen an unsere Support-Adresse gesendet werden, häufig wegen fehlendem Inhalt abgelehnt (Email::Receiver::NoBodyDetectedError). Diese E-Mails enthalten jedoch oft tatsächlich Text im Body, sodass es möglicherweise ein Problem bei der Analyse gibt.
Abgesehen von der Behebung der Ursache für diese fehlerhaften Ablehnungen wäre ich froh, wenn wir bei neuen Ablehnungen benachrichtigt würden, damit wir diese prüfen und feststellen können, ob die Ablehnung gerechtfertigt war.
Das könnte in Form einer Option geschehen, bei der bei allen Ablehnungen Benachrichtigungen an das Personal gesendet werden, oder als Option, bei der alle Ablehnungs-E-Mails einfach an das Personal weitergeleitet (CC) werden.
Andererseits müssten wir, wenn wir keine eingehenden Support-E-Mails verpassen wollen, die Liste der abgelehnten E-Mails im Discourse-Backend kontinuierlich abfragen. Das ist mühsam und unnötig.
Nun… ‘oft’ im Sinne von ‘oft genug, um ziemlich nervig zu sein’. Unser Hauptanliegen ist, dass sich niemand über eine wahrgenommene mangelnde Reaktion unseres Support-Teams ärgert.
Ich habe nach Mustern in den Fällen gesucht, die mir aufgefallen sind. Ursprünglich dachte ich, es könnte ein Problem mit der Art und Weise geben, wie mac.com E-Mails verarbeitet. Ich habe jedoch festgestellt, dass wir etwa 30 Nutzer mit mac.com-Adressen haben, bei denen keine Probleme auftreten.
Ich dachte auch, wenn mac.com einen Webmail-Client hätte, könnte dieser HTML-E-Mails auf nicht standardkonforme Weise verarbeiten. Aber ich bin mir nicht einmal sicher, ob es überhaupt einen mac.com-Webmail-Client gibt.
Ich glaubte, die Lösung gefunden zu haben, als mir klar wurde, dass der jüngste Vorfall eine E-Mail betraf, die im Körper nur zitierte Zeilen enthielt. Nachfolgende Tests zeigten jedoch, dass Discourse solche E-Mails problemlos verarbeitet.
Ich werde die Protokolle überprüfen, um zu sehen, wie oft so etwas bereits passiert ist, und natürlich nach Mustern suchen. Ich dachte nur, dass eine Warn-E-Mail eine einfache Vorsichtsmaßnahme ist, solange die Möglichkeit besteht, dass Discourse gelegentlich solche Fehler macht.
Ich werde die Ergebnisse meiner Untersuchung hier veröffentlichen.
Sie haben an eine Adresse gesendet, die Sie nicht bearbeiten, wie z. B. support.
Für mich sieht nur der „no body“-Fall, bei dem Sie angeben, dass einer vorhanden ist, wie ein möglicher Fehler aus. Eine Möglichkeit ist, dass dies damit zusammenhängt, dass sie einen alten und fehlerhaften E-Mail-Client verwenden.
Ich habe einige dieser Fälle (Email::Receiver::BadDestinationAddress) geprüft, und viele davon scheinen legitime Antworten von Kunden zu sein, wobei der Empfänger in folgender Form angegeben ist: replies+langeKennung@discourse.site.com. Die Warn-E-Mail, die Discourse an den Absender sendet, legt nahe, dass ihre E-Mail von einer anderen Adresse als der mit dem verknüpften Thema verbundenen gesendet wurde, was wahrscheinlich die Erklärung ist. In einem solchen Fall würde ich jedoch trotzdem möchten, dass das Personal benachrichtigt wird.
Das sieht tatsächlich nach einem Fehler aus, aber obwohl ich gerne sehen würde, dass dies behoben wird, bin ich der Meinung, dass es immer solche Fälle geben wird. Daher wäre es zusätzlich zur Untersuchung möglicher Fehler beim Parsen von E-Mails sinnvoll, eine Warn-E-Mail an das Personal zu senden, damit wir in der Zwischenzeit zeitnah unterstützen können.
Genau das habe ich auch gedacht. Das nächste Mal, wenn ich so einen Fall sehe, werde ich den Kunden fragen, welchen E-Mail-Client er verwendet.
Was ich sagen möchte, ist, dass abgelehnte E-Mails manchmal einfach von Personen stammen, die Support benötigen, und nichts Böswilliges dahintersteckt.
Zwar müssen einige der von Discourse abgelehnten E-Mails tatsächlich abgelehnt werden, aber wir wollen kein Risiko eingehen, Support-E-Mails zu verpassen, daher sind wir gezwungen, die Liste der abgelehnten Nachrichten abzufragen.
In der Zwischenzeit sind verwirrte Absender gezwungen, andere Wege zu finden, um uns zu erreichen, wie zum Beispiel das Kontaktformular auf unserer Website.
Für größere Seiten könnten E-Mail-Ablehnungsmeldungen zu zahlreich sein, um sie zu bewältigen, aber für uns wäre es viel einfacher, diese zu handhaben, als mit verärgerten Kunden umgehen zu müssen.
Außerdem senden zwar Discourse-Ablehnungsmails an den Absender mit potenziell nützlichen Informationen, aber ich denke, diese E-Mails landen manchmal in Spam-Ordner, was die betroffenen Kunden weiter verwirrt.
Ich bin mir jedoch nicht sicher, wie man das Problem mit Antworten aus dem falschen Postfach lösen kann. (Und Mann, wie sehr ich Kontaktformulare hasse – egal auf welcher Seite ich gerade stehe!)
Wenn ein Benutzer von einer anderen Adresse antwortet als die, an die die E-Mail gesendet wurde, ist das zu erwarten.
Wenn wir Antworten auf diese E-Mails von einer anderen E-Mail-Adresse zulassen würden, würden wir Konten dafür anfällig machen, dass sie per E-Mail missbraucht werden, indem sich andere als ein anderer Benutzer ausgeben. Wir stoßen hier auf Meta manchmal auf dieses Problem bei unseren eigenen Support-Nachrichten.
Wenn Kontakt-E-Mail-Formulare verwendet werden, senden sie in der Regel von einer E-Mail-Adresse und setzen den Reply-To-Header. Das bedeutet, dass wir auf dasselbe Problem stoßen, das oben beschrieben wurde.
Ich persönlich habe keine großartige Lösung dafür – vielleicht hat jemand anderes im Team eine Idee.
Ja, wie ich bereits sagte, macht es Sinn, diese abzulehnen. Ich möchte jedoch trotzdem benachrichtigt werden, wenn dies geschieht.
Ich habe Kontaktformulare nur deshalb erwähnt, weil Kunden, wenn sie unseren Support über die Support-E-Mail-Adresse (die von Discourse verarbeitet wird) nicht erreichen können, gezwungen sind, nach Alternativen zu suchen, was nicht ideal ist.
Ich bin mir nicht sicher, wie das genau umzusetzen ist. Du kannst /admin/email/rejected beobachten, aber um eine echte Benachrichtigung zu erhalten, benötigst du derzeit ein Plugin.
Ich auch nicht, deshalb habe ich dies als Feature-Anfrage gepostet.
Ja, verstanden. Aber jede paar Minuten auf diese Seite zu gehen und zu aktualisieren, scheint ziemlich ineffizient zu sein.
Ein Plugin wäre in Ordnung, aber ich verstehe nicht, warum diese Funktion nicht einfach zu Discourse hinzugefügt werden könnte. Für mich klingt das nach einer Selbstverständlichkeit. Discourse sendet bereits verschiedene Benachrichtigungen an Site-Administratoren und Mitarbeiter. Stelle die Einstellung (Benachrichtigung bei E-Mail-Ablehnung) standardmäßig auf „deaktiviert
Ein weiteres Beispiel: Ein Kunde hat eine E-Mail an die Support-Adresse gesendet, um ein Problem mit seinem Kauf zu melden. Discourse hat die E-Mail abgelehnt: [Email::Receiver::InactiveUserError].
Ich verstehe, dass es für Discourse absolut sinnvoll ist, E-Mails von inaktiven Benutzern abzulehnen. Wenn unser Support-Team jedoch gleichzeitig benachrichtigt würde, könnte es sofort auf den Kunden zugehen, ihm erklären, was passiert ist, und mitteilen, welche Möglichkeiten es gibt.
Stattdessen steht der Kunde nun, sofern wir die Liste der abgelehnten Nachrichten nicht häufig abfragen, vor zwei Problemen, die beide auf automatisierte Systeme zurückzuführen sind und von denen unser Support-Team nichts mitbekäme. Eine menschliche Intervention in dieser Phase ist wichtig, aber es kann zu Verzögerungen bei der Reaktionszeit kommen, da wir erneut auf das manuelle Überprüfen der Liste der abgelehnten Nachrichten angewiesen sind.
Gibt es einen technischen Grund, warum Administratoren nicht über E-Mail-Ablehnungen benachrichtigt werden können?
