Si è verificato di nuovo Discourse::InvalidAccess. Questa volta, la lunghezza dell’Oggetto non è la causa. Sospetto che abbia a che fare con la categoria che è una sottocategoria ristretta. Ma la categoria è impostata per ricevere email da indirizzi senza un account, quindi mi aspetterei che l’email venga elaborata e crei un nuovo argomento.
Il caso d’uso è un CFP: le persone dovrebbero essere in grado di inviare messaggi, ma solo gli organizzatori dovrebbero essere in grado di leggere i messaggi e discuterne. Penso che questo sia diverso dal caso descritto in Email in to a private category
Ho ricostruito dopo un git pull (noop), e ora sembra funzionare con il secondo dominio aggiunto a relay_domains di Postfix. Prima di questa serie di test, e con la modifica, non ho più avuto errori, ma le email non sono apparse affatto, né nella categoria né nei log degli errori.
(Naturalmente, example.net non è ciò che è effettivamente nel file di configurazione. Ciò che c’è è il nome host del forum e il nome del dominio padre, entrambi configurati nel DNS)
Ho notato che @mpalmer menzionò anni fa che aggiungere un secondo dominio poteva essere fatto ma
Quindi mi aspettavo che la piccola configurazione relay_domains non fosse sufficiente, ma sembra funzionare, dato che fai git pull prima di ricostruire. Ci deve essere una qualche stranezza nel modo in cui il container mail-receiver viene costruito che non riesce ad aggiornare pups…
In qualche modo il fallimento è ritornato. È un po’ ridicolo, perché i test precedenti erano andati bene. Ora, dopo un’altra ricostruzione, le email in arrivo vengono nuovamente rifiutate. Ho dovuto ripetere la procedura git pull e poi rebuild, ma questa volta non sembra aver funzionato.
Sospetto che la situazione delle sottocategorie possa influire, a meno che qualcosa non sia cambiato nel modo in cui vengono gestite le email in arrivo per quanto riguarda i permessi delle categorie.
La situazione attuale è che le persone inviano email e ricevono email di rifiuto, quindi devo copiare e incollare le email rifiutate e assegnare gli argomenti al mittente originale. L’ “esperienza utente” è quindi terribile e l’overhead è piuttosto fastidioso.
Non posso davvero accettare che l’email in arrivo sia una categoria pubblica, questo è il senso di fare un CFP. Ma Discourse ora sembra incapace di servire questo scopo.
Per coloro che hanno un account ma non hanno accesso alla categoria, ci si aspetta che vengano rifiutati. L’opzione Accetta email da utenti anonimi senza account si applica solo agli utenti “staged” (temporanei), e a coloro che hanno un account esistente vengono applicate le autorizzazioni della categoria.
È strano che vengano rifiutate persone senza account. Potrebbe essere dovuto alle modifiche apportate al ricevitore di posta?
Sembra che il rifiuto sia gestito dall’endpoint /admin/email/smtp_should_reject.json.
Ho apportato la modifica perché le email venivano respinte. Ho prima aggiunto più email all’indirizzo email in arrivo (separandole con |) e questo sembrava funzionare.
OK, questo ha senso. Ma è un po’ confuso. Se “chiunque” può inviare email, ma gli utenti esistenti no, questo vanifica lo scopo.
Controllerò le email rifiutate per vedere se sono in fase di staging o meno. Grazie mille per l’aiuto nel debug @JammyDodger.
Penso che tu abbia ragione @JammyDodger, gli utenti appena registrati passano, gli utenti esistenti con accesso normale alla categoria passano, ma gli account esistenti senza accesso non possono inviare email alla categoria.
Immagino che una soluzione alternativa sarebbe creare un gruppo CFP senza alcuna notifica per la categoria che comprenda tutti gli utenti esistenti. Ma sembra molto complicato e potrebbe avere effetti collaterali di cancellazione delle notifiche esistenti… Non sono sicuro di cosa fare.
Data una categoria privata con l’invio di email autorizzato per indirizzi email sconosciuti (cioè, appartenenti a nessun account esistente, AKA utente in staging)
\u003e se arriva un’email da un indirizzo sconosciuto: viene consegnata alla categoria privata
\u003e se arriva un’email da un indirizzo conosciuto: viene consegnata se e solo se l’utente è membro di un gruppo autorizzato ad accedere alla categoria.
Pertanto, se si desidera utilizzare l’invio di email per un CFP, configurare l’invio di email di un gruppo privato e utilizzare quell’indirizzo. I messaggi possono essere “resi pubblici” e trasformati in un argomento in una categoria (privata o meno).
