Questa nota ha lo scopo di riassumere la mia esperienza di amministrazione mentre silenzi alcuni utenti. Non sto necessariamente chiedendo modifiche, ma cito le sfide che potrebbero tradursi in richieste in fase di revisione.
Quando devo silenziare un utente a causa di email non recapitate, non voglio che gli venga inviata un’email per notificarlo dell’evento.
Non vedo un’opzione di amministrazione per aggiungere un motivo di silenzio personalizzato all’elenco esistente. Vorrei aggiungere “Email non recapitate”.
Vorrei impostare una delle opzioni di periodo di silenzio disponibili come predefinita. Non voglio dover impostare il periodo di tempo dal menu a discesa per ogni evento.
Voglio avvisare l’utente sul motivo per cui è stato silenziato, con maggiori informazioni rispetto alla singola riga “motivo”. La casella è presente per inviare un’email all’utente con una nota, ma ancora una volta, questa invia un’email all’utente. Voglio solo inviargli un messaggio perché so che l’email non funziona.
Vengono inviate altre email di Discourse a un utente dopo che è stato bloccato o silenziato? Per questo scenario specifico e forse altri, non voglio che vengano inviate altre email a questo utente, specialmente se si è iscritto a molte notifiche.
Riguardo all’eliminazione di un utente in questo stesso scenario: possiamo semplicemente eliminare l’utente e possiamo anche “eliminare e bannare sia l’indirizzo email che l’indirizzo IP”. Perché sono collegati? Mi piace l’idea di bannare un indirizzo email. Raramente potrei voler bannare un indirizzo IP. Ma bannare un IPv4 è scomodo per una serie di motivi - forse va bene con IPv6 ma non ci siamo ancora. Finché questi concetti non saranno separati, non potremo semplicemente bannare un indirizzo email? Se conoscessi meglio gli interni di Discourse, sarei felice di creare uno script per pulire elementi specifici dagli elenchi di ban, ma non so dove trovare quei dati.
Abbiamo MaxMind attivo per questo sito e vorrei utilizzare l’indirizzo IP per ottenere una posizione per aiutare a determinare se l’utente debba essere semplicemente silenziato o eliminato. Ad esempio, se l’ultimo indirizzo utilizzato è distante dall’indirizzo di registrazione (più altre metriche), allora eliminerei l’account per semplice sospetto. Ma il popup che mostra le informazioni sull’IP non mostra una posizione. È un bug o dovrei controllare di nuovo MaxMind?
Ricevo avvisi di mancato recapito al mio indirizzo postmaster@ - è così che so che le email dal forum non vengono recapitate. Qualcuno potrebbe suggerire di controllare il Punteggio di Mancato Recapito per i cutoff automatici per evitare di inviare email a qualcuno che ha già registrato mancate consegne. Non abbiamo dati di mancato recapito per il punteggio, non ho configurato Discourse per interrogare POP3 (IMAP??) per tali dati. Tutto ciò che vedo nei meta sono aneddoti del forum sull’impostazione. Esiste una documentazione dedicata e reale su questo argomento?
Ancora una volta, tutto questo serve solo a condividere l’esperienza utente (non ottimale) in quest’area specifica, per chiunque possa essere interessato.
Non ho ancora configurato la soglia del punteggio di rimbalzo perché non ho Discourse che controlla le email per le notifiche di rimbalzo. Le informazioni in questo thread meta sono le migliori che ho trovato sull’argomento della configurazione per elaborare i rimbalzi. Nei prossimi giorni sono alla ricerca di documentazione più completa.
Ma sì, oggi sto impostando una soglia di rimbalzo molto bassa.
{“translation”: “[quote="Architect, post:6, topic:323151"]Deve esserci una ragione scelta o scritta prima che sia possibile silenziare un account.[/quote]\nQuesto ha senso perché viene inviato un messaggio sito all’utente per informarlo dell’evento. Quel messaggio del sito non è chiaro su cosa vogliamo esattamente che l’utente faccia. Quindi, dopo che il messaggio è stato inviato, invio una risposta a quel messaggio all’utente, chiedendogli di rispondere quando ha corretto la situazione dell’email.\n\nQuindi le sfide dei principianti che devo affrontare ora includono:\n\n- Voglio quel messaggio all’utente, ma preferirei modificare il testo. Cambiare admin/customize/email_templates/system_messages.email_revoked per l’inglese non lo cambia per tutte le altre lingue. O c’è una funzione per eseguire una traduzione automatica su uno o tutti i sistemi di messaggi?\n- Senza una ricerca su admin/customize/email_templates/ è difficile trovare il testo corretto dei sistemi o notifiche utente da modificare e sapere quali processi li attivano.\n- Non voglio inviare un’email quando il problema, per definizione, è che non stanno ricevendo email.\n- Quando invio quella risposta al messaggio di sistema sul loro profilo utente, viene inviata un’altra email. Se possiamo bloccare efficacemente la posta in uscita all’indirizzo, questo non accadrà. Vale a dire, tutte le funzioni di posta in uscita passano attraverso un processo centrale che verifica se la soglia di bounce è stata superata? Oppure mi manca una funzione legata al Silenzio che blocca la posta in uscita senza dover legare quella decisione alla soglia di bounce?\n- Idealmente, quando l’utente sostituisce l’indirizzo email con uno valido, o clicca su un pulsante “il mio indirizzo è ora OK”, sarebbe fantastico che il server inviasse una mail di test e, in caso di successo, cancella il flag / contatore di bounce.\n- (Casuale) Ci sono un numero fisso di motivi di sospensione admin_js.admin.user.suspend_reasons e sono “duri” per impedirne la personalizzazione per uno scopo diverso. Ossia, possiamo cambiare il testo di admin_js.admin.user.suspend_reasons.combative e c’è un singolo admin_js.admin.user.suspend_reasons.custom, ma non sembra possibile creare un nuovo admin_js.admin.user.suspend_reasons.bouncing_email.\n\nQuesto scenario non si applica solo ai bounce. Riesco a pensare ad altri scenari in cui vorremmo notificare all’utente con un messaggio locale che non possiamo inviargli email e fornirgli un messaggio personalizzato memorizzato che gli dica cosa fare.\n\n Sospetto che tutto questo descriva un comportamento molto fine-tuned che probabilmente non emerge nella lista delle priorità, ma non so ancora se o come gli altri affrontano questa situazione. Grazie per la pazienza…”}
Ho appena trovato questa documentazione per configurare la gestione dei bounce:
Anche le immagini qui sono estremamente utili:
L’implementazione di questa funzionalità dovrebbe affrontare abbastanza delle sfide qui per gestire efficacemente le email respinte. Devo ancora capire esattamente come notificheremo una base di utenti multilingue in modo efficace e li rimetteremo rapidamente in carreggiata quando avranno risolto i problemi di posta elettronica. Cioè, quando avranno apportato una modifica efficace dovranno notificarci o al sistema in modo che i blocchi nei loro confronti possano essere rimossi.
Quando un indirizzo e-mail restituisce le e-mail automatiche di discourse, sembra che non avresti necessariamente bisogno/voler silenziare o eliminare il loro account per questo, a meno che tu non sospetti che sia un account di spoofing o qualcosa senza un’e-mail valida.
Suppongo che questo sia probabilmente il motivo per cui vorresti mettere temporaneamente in attesa l’account per convalidare che abbiano un’e-mail funzionante, hai un alto volume di casi come questo o è pratico gestirli uno per uno manualmente?
Ci sono alcune altre opzioni come modificare manualmente le impostazioni di notifica e-mail, o cambiare temporaneamente l’indirizzo e-mail non funzionante con un altro indirizzo funzionante controllato dall’amministratore o qualcosa del genere. Potrebbe non essere la migliore idea, solo alcune idee casuali qui.
Quando un account viene eliminato, non invia una notifica e-mail al riguardo l’ultima volta che ho controllato. Una politica semplice ma un po’ brutale è eliminare gli account se non hanno un’e-mail funzionante.
Siamo sulla stessa lunghezza d’onda. Ci sono scenari diversi che manager diversi vorranno gestire in modo diverso. Sto esplorando questo software per capire cosa fa, come è inteso per essere utilizzato e come altri lo utilizzano.
L’obiettivo sottostante di questa iniziativa/indagine è duplice: primo, evitare proattivamente gli abusi. Secondo, evitare l’invio di email che rimbalzano, il che potrebbe comportare la segnalazione del nostro sito come fonte di email non recapitate. Ciò può comportare inserimenti temporanei nelle RBL e voglio evitare tali sciocchezze.
Non abbiamo un volume elevato per questo sito, ma ci sono gruppi di utenti, simili ma diversi da TL0-4. Gli utenti di un gruppo non dovrebbero essere silenziati se qualcosa va storto con la loro email. Gli utenti di un altro gruppo con alcuni post recenti pertinenti all’argomento non dovrebbero essere silenziati. Gli account senza attività o senza attività valida recente potrebbero essere silenziati per attirare la loro attenzione se dovessero tornare.
Il concetto di silenziare le persone per attirare la loro attenzione è imbarazzante. E non mi interessano molto gli indirizzi email. L’intento reale è che se abbiamo un indirizzo email fasullo, ritengo che un account sia più propenso a essere una fonte di abuso. Quindi li silenzierò preventivamente, cercherò una risposta e, se non avremo loro notizie per un lungo periodo, eliminerò semplicemente l’account. Un utente partecipante (TL1?) da cui non abbiamo più notizie da molto tempo potrebbe essere messo in silenzio/revisione a lungo termine.
Dato che siamo qui, tutto ciò implica anche che le persone creano account senza un’email valida o cambiano i loro indirizzi in qualcosa di non valido. Sto esaminando la Documentation e vorrei creare un’automazione per: silenziare i nuovi utenti TL0 fino a dopo che avranno visualizzato un paio di thread, quindi inviare loro un’email. Se riceviamo un rimbalzo da questi messaggi specifici, li metteremo in stato di revisione. Quindi nessuna email di benvenuto fino a quando non saremo sicuri che siano umani che navigano sul sito, e nessun permesso finché non saremo sicuri che verifichino la loro email.
Per quanto ne so, non è possibile attivare il tuo account senza prima verificare la tua email (a meno che non venga attivato manualmente da un amministratore o tu stia utilizzando l’SSO e non verifichi con il tuo IdP).
Non è necessariamente vero, ci sono altri motivi come l’e-mail potrebbe essere temporaneamente disattivata, o hanno bannato il tuo mittente (che potrebbe anche essere temporaneo, come un silenzio temporaneo dell’account).
Il primo passo che consiglierei per quello che stai descrivendo sarebbe inviare un PM regolare a un utente se la sua e-mail non riceve messaggi come avviso in caso non ne sia a conoscenza, puoi renderlo un PM di avviso ufficiale con la casella di controllo per rendere l’icona di avviso della busta rossa invece che verde. Questo mette anche una nota sul loro account che hanno ricevuto uno o più PM di avviso ufficiali, in modo da avere quella documentazione.
Come menzionato con le impostazioni predefinite, i nuovi account devono essere validati cliccando sul link nell’e-mail di verifica prima di poter utilizzare il tuo sito, a meno che tu non abbia aggirato questo.
Ciò sembra essere fondamentalmente già abilitato con le impostazioni predefinite, anche se TL0 può inviare risposte/argomenti pubblici ma non può inviare messaggi PM a nessuno finché non viene promosso al livello base TL1, che richiede un po’ di lettura e l’e-mail dovrebbe essere validata prima di ciò.
