Ich habe mir den Code angesehen und es scheint mir, dass:
authserv_id aktiviert istEmail::AuthenticationResults wird entweder ein Urteil „fail“ oder „pass“ zuweisen, was zu einer Aktion „enqueue“ oder „accept“ führtlib/new_post_manager.rb - self.post_needs_approval?)Ist meine Schlussfolgerung richtig?
Bedeutet dies, dass Spoofing-Versuche wahrscheinlich zur Überprüfung gelangen würden?
So lala, dies wird in die Genehmigungs-Warteschlange gesendet, wenn DMARC fehlschlägt, aber wenn es überhaupt nicht vorhanden ist, wird es trotzdem durchgehen.
Vielleicht wäre eine Möglichkeit, voranzukommen, eine explizite Website-Einstellung hinzuzufügen, die im Grunde besagt: „Website-Betreiber akzeptiert Risiko“, und wenn diese aktiviert ist, ermöglicht sie die Zuordnung basierend auf E-Mail.
Ich bin etwas verwirrt von der Debatte über Fehler vs. beabsichtigtes Verhalten. So wie ich es verstanden habe, ist die Erstellung neuer Themen per E-Mail aus Sicherheitsgründen nicht gestattet, wenn die E-Mail-Adresse mit einem bestehenden, nicht-gestagten Benutzer übereinstimmt. Dies liegt daran, dass E-Mail-Adressen gefälscht werden können und Benutzer daher identifiziert werden könnten.
Antworten sind vermutlich akzeptabel, da die Adresse den Antwortschlüssel enthält, was zeigt, dass der Absender der Empfänger der Benachrichtigungs-E-Mail war und somit wahrscheinlich der echte Benutzer ist.
Wenn diese Interpretation des beabsichtigten Verhaltens korrekt ist, widerspricht sie dem, was ich tatsächlich erlebe. Wenn mein Benutzer die Berechtigung hat, in der Kategorie zu erstellen, und ich eine E-Mail von meiner registrierten E-Mail-Adresse an die email_in-Adresse der Kategorie sende, wird die E-Mail-Adresse meinem Benutzer zugeordnet und ein neues Thema von meinem Benutzer erstellt.
Dies geschieht unabhängig davon, ob Akzeptiere E-Mails von anonymen Benutzern ohne Konten aktiviert ist, da mein Benutzer die Berechtigung zur Erstellung hat.
Die aktuelle Situation scheint zu sein: (mit E-Mail in anonyme Benutzer aktiviert)
(Hinweis: Ich habe 4 gerade nicht getestet) Mit aktivierter E-Mail in anonyme Benutzer würde ich erwarten, dass 3 und 4 immer gleich funktionieren. Ob beide abgelehnt werden, um Identitätsdiebstahl zu verhindern, oder beide akzeptiert werden, basierend auf der Annahme, dass ein echter Benutzer nicht weniger Berechtigungen als ein anonymer Benutzer haben sollte, sie sollten keine unterschiedlichen Ergebnisse haben.
Beim OP geht es ausschließlich um gesicherte Kategorien (z. B. eine Kategorie, die anonyme Benutzer nicht einmal sehen können). In diesem Fall würden gestufte Benutzer heute sicherlich abgelehnt werden, oder?
Ja, E-Mails von gestuften/nicht aktivierten Benutzern wären (sollten?) in meinem ursprünglichen Szenario nicht angenommen worden.
Ich habe dies gerade getestet, um das Verhalten auf unserer Instanz zu bestätigen (20 Commits zurück, kann nichts damit zusammenhängendes in den Änderungen sehen). Wir haben alle Beiträge von Benutzern mit Vertrauensstufe 0, die genehmigt werden müssen, und ich war mir nicht sicher, ob dies die Route beeinflussen würde, also habe ich die Schritte erweitert, um dies zu testen, ohne dass dies stört.
Diese Schritte beziehen sich alle auf eine Kategorie, in der die Admin-Gruppe Lese-/Antwort-/Erstellungsrechte hat und keine anderen Berechtigungen festgelegt sind, eine E-Mail-Adresse festgelegt ist und E-Mails von anonymen Benutzern ohne Konto akzeptieren aktiviert ist.
„>“ bezeichnet eine Auswirkung und keine Aktion.
Wenn dies nicht geschehen wäre, hätte die Einstellung E-Mails von anonymen Benutzern ohne Konto akzeptieren keinen Zweck für Kategorien, die weder jeder noch trust_level_0 mit Erstellungsberechtigung haben.
Ich glaube, dies entspricht #4 im OP, wo der OP beschreibt, dass sowohl #3 als auch #4 zu einem neuen Thema führen sollten, aber nur #4 dies tut.
Mit meinem vorherigen Beitrag (vor „Die aktuelle Situation“) wollte ich diesen Punkt hauptsächlich allgemeiner diskutieren, was dafür spricht, dass #3 nicht funktionieren sollte, da die aktuelle Funktionsweise vor Identitätsdiebstahl schützt.
Wie ich jedoch in diesem Beitrag beschreibe, existiert dieser Schutz nicht, wenn ein übereinstimmender Benutzer die Erstellungsberechtigung hat.
Es ist immer noch ein Problem unter 3.6.0.beta3-latest.