Der Fehler Discourse::InvalidAccess ist erneut aufgetreten. Diesmal ist die Länge des Betreffs nicht die Ursache. Ich vermute, dass es mit der Kategorie zusammenhängt, die eine eingeschränkte Unterkategorie ist. Die Kategorie ist jedoch so eingestellt, dass sie E-Mails von Adressen ohne Konto empfängt. Daher würde ich erwarten, dass die E-Mail durchgeht und ein neues Thema erstellt wird.
Der Anwendungsfall ist ein CFP (Call for Papers): Leute sollten in der Lage sein, Nachrichten zu senden, aber nur Organisatoren sollten die Nachrichten lesen und darüber diskutieren können. Ich denke, dies unterscheidet sich von dem Fall, der in Email in to a private category beschrieben wird.
Ich habe nach einem (noop) git pull neu erstellt, und jetzt scheint es mit der zweiten Domain, die zu Postfix’ relay_domains hinzugefügt wurde, zu funktionieren. Vor dieser Testreihe und mit der Änderung hatte ich keine weiteren Fehler, aber E-Mails erschienen überhaupt nicht, weder in der Kategorie noch in den Fehlerprotokollen.
(Natürlich ist example.net nicht das, was tatsächlich in der Konfigurationsdatei steht. Dort steht der Hostname für das Forum und der Name der übergeordneten Domain, die beide in der DNS konfiguriert sind.)
Ich habe bemerkt, dass @mpalmer vor Jahren erwähnt hat, dass das Hinzufügen einer zweiten Domain möglich sei, aber
Daher erwartete ich, dass die kleine relay_domains-Konfiguration nicht ausreichen würde, aber sie scheint zu funktionieren, vorausgesetzt, Sie führen git pull vor dem Neuerstellen aus. Es muss eine Eigenart in der Art und Weise geben, wie der mail-receiver-Container erstellt wird, die dazu führt, dass pups nicht aktualisiert wird…
Irgendwie ist der Fehler zurückgekehrt. Das ist ein bisschen lächerlich, weil frühere Tests in Ordnung waren. Jetzt, nach einem weiteren Rebuild, wird eingehende E-Mail wieder abgelehnt. Ich habe wiederholt den git pull und dann den rebuild Tanz wiederholt, aber dieses Mal schien es nicht zu funktionieren.
Ich vermute, die Unterkategorie-Situation könnte eine Rolle spielen, es sei denn, etwas hat sich geändert in der Art und Weise, wie eingehende E-Mails in Bezug auf Kategorieberechtigungen behandelt werden.
Die Situation ist jetzt, dass Leute E-Mails senden und Ablehnungs-E-Mails erhalten, so dass ich die abgelehnten E-Mails kopieren und einfügen und die Themen dem ursprünglichen Poster zuweisen muss. Das “Benutzererlebnis” ist daher schrecklich und der Aufwand ist ziemlich ärgerlich.
Ich kann eingehende E-Mails nicht wirklich als öffentliche Kategorie akzeptieren, das ist der Sinn der Sache, ein CFP zu machen. Aber Discourse scheint jetzt nicht mehr in der Lage zu sein, diesen Zweck zu erfüllen.
Für diejenigen, die ein Konto haben, aber keinen Zugriff auf die Kategorie haben, wird erwartet, dass diese abgelehnt werden. Die Option E-Mails von anonymen Benutzern ohne Konto akzeptieren gilt nur für staged users, und diejenigen mit einem bestehenden Konto haben die Kategorieberechtigungen angewendet.
Es ist seltsam, dass Benutzer ohne Konto abgelehnt werden. Könnte dies an den Änderungen liegen, die Sie am Mail-Empfänger vorgenommen haben?
Anscheinend wird die Ablehnung vom Endpunkt unter /admin/email/smtp_should_reject.json behandelt.
Ich habe die Änderung vorgenommen, weil E-Mails zurückkamen. Ich habe zuerst mehrere E-Mails zur eingehenden E-Mail-Adresse hinzugefügt (getrennt durch |) und das schien zu funktionieren.
OK, das ergibt Sinn. Aber es ist etwas verwirrend. Wenn “jeder” E-Mails senden kann, aber bestehende Benutzer nicht, widerspricht das irgendwie dem Zweck.
Ich werde die abgelehnten E-Mails überprüfen, ob sie staged sind oder nicht. Vielen Dank für Ihre Hilfe bei der Fehlersuche, @JammyDodger.
Ich glaube, Sie haben Recht, @JammyDodger. Gestellte Benutzer werden durchgelassen, bestehende Benutzer mit normalem Zugriff auf die Kategorie werden durchgelassen, aber bestehende Konten ohne Zugriff können keine E-Mails an die Kategorie senden.
Ich schätze, eine Problemumgehung wäre, eine CFP-Gruppe ohne Benachrichtigung für die Kategorie zu erstellen, die alle bestehenden Benutzer umfasst. Aber das klingt sehr umständlich und könnte Nebenwirkungen wie das Abbrechen bestehender Benachrichtigungen haben … Ich bin mir nicht sicher, was ich tun soll.
Gegeben eine private Kategorie mit E-Mail-Eingang, der für unbekannte E-Mail-Adressen autorisiert ist (d. h. die zu keinem bestehenden Konto gehören, auch bekannt als gestufter Benutzer)
\u003e Wenn eine E-Mail von einer unbekannten Adresse eingeht: Sie wird an die private Kategorie geliefert
\u003e Wenn eine E-Mail von einer bekannten Adresse eingeht: Sie wird genau dann geliefert, wenn der Benutzer Mitglied einer Gruppe ist, die zum Zugriff auf die Kategorie autorisiert ist.
Wenn Sie also E-Mail-Eingang für einen CFP verwenden möchten, konfigurieren Sie den E-Mail-Eingang einer privaten Gruppe und verwenden Sie diese Adresse. Nachrichten können “öffentlich gemacht” und in ein Thema in einer Kategorie (privat oder nicht) umgewandelt werden.
