Ho esaminato il codice e mi sembra che:
authserv_id è abilitatoEmail::AuthenticationResults assegnerà un verdetto di fallimento o successo, che si traduce in un’azione di accodamento o accettazionelib/new_post_manager.rb - self.post_needs_approval?)Il mio ragionamento è corretto?
Ciò significa che i tentativi di spoofing finirebbero probabilmente in revisione?
In un certo senso, questo verrà inviato alla coda di approvazione se DMARC fallisce, ma se è completamente assente passerà comunque.
Forse un modo per andare avanti sarebbe aggiungere un’impostazione esplicita del sito che dica essenzialmente “l’operatore del sito accetta il rischio” e, se abilitata, consenta il mapping basato sull’e-mail.
Sono un po’ confuso dal dibattito tra bug e comportamento previsto. Il modo in cui l’ho interpretato è che, per motivi di sicurezza, la creazione di nuovi argomenti via email non è consentita se l’indirizzo email corrisponde a un utente non in staging esistente; questo perché gli indirizzi email possono essere falsificati e quindi gli utenti potrebbero essere impersonati.
Le risposte sono presumibilmente accettabili perché l’indirizzo include la chiave di risposta, dimostrando che il mittente era il destinatario dell’email di notifica e quindi è probabilmente l’utente reale.
Se tale interpretazione del comportamento previsto è corretta, è in contraddizione con ciò che sto effettivamente sperimentando. Se il mio utente ha il permesso di creare nella categoria e invio un’email dal mio indirizzo email registrato all’indirizzo email_in della categoria, l’indirizzo email viene associato al mio utente e viene creato un nuovo argomento dal mio utente.
Ciò accade indipendentemente dal fatto che accetta email da utenti anonimi senza account sia abilitato, poiché il mio utente ha il permesso di creare.
La situazione attuale sembra essere: (con l’email in utenti anonimi abilitata)
(Nota: non ho testato il punto 4 ora) Con l’email in utenti anonimi abilitata, mi aspetterei che 3 e 4 si comportino sempre allo stesso modo. Sia che vengano entrambi rifiutati per proteggere dall’impersonificazione, sia che vengano entrambi accettati sulla base del fatto che un utente reale non dovrebbe avere meno permessi di un utente anonimo, non dovrebbero avere risultati diversi.
L’OP riguarda interamente le categorie protette (ad esempio una categoria che gli utenti anonimi non possono nemmeno vedere). In tal caso, gli utenti in staging verrebbero certamente rifiutati oggi, no?
Sì, l’email dagli utenti in staging/non attivati non sarebbe stata (non avrebbe dovuto essere?) accettata nel mio scenario originale.
Ho appena testato per confermare il comportamento sulla nostra istanza (20 commit indietro, non riesco a vedere nulla di correlato nelle modifiche). Abbiamo impostato che tutti i post degli utenti di trust level 0 richiedano l’approvazione e non ero sicuro se ciò avrebbe influito sul percorso, quindi ho esteso i passaggi per testare senza che ciò interferisse.
Questi passaggi si riferiscono tutti a una categoria in cui il gruppo admin ha i permessi di visualizzazione/risposta/creazione e non sono impostate altre autorizzazioni, è impostato un indirizzo email e l’opzione accept emails from anonymous users with no accounts è abilitata.
“>” denota un effetto piuttosto che un’azione.
Se ciò non fosse accaduto, l’impostazione accept emails from anonymous users with no accounts non avrebbe alcuno scopo per le categorie che non hanno né everyone né trust_level_0 con permesso di creazione.
Credo che questo sia equivalente al punto #3 dell’OP, dove l’OP descrive che sia il #3 che il #4 dovrebbero risultare in un nuovo argomento, tuttavia solo il #4 lo fa.
Con il mio post precedente (https://meta.discourse.org/t/category-not-accepting-anonymous-email-from-known-users/42871/25?u=simon_manning) (prima di “The current situation”), il mio obiettivo principale era discutere questo punto in modo più generale, il che sembra sostenere che il #3 non dovrebbe funzionare perché il modo in cui funziona attualmente protegge gli utenti dall’essere impersonati.
Tuttavia, come descrivo in quel post, tale protezione non esiste dove un utente corrispondente ha il permesso di creazione.
È ancora un problema su 3.6.0.beta3-latest.