Richieste di funzionalità: account email separato per i riassunti

Contribuisci Funzionalità
1

Da un principiante: oggi abbiamo avuto l’esperienza di vedere tutte le nostre email praticamente bloccate, e gli utenti non potevano registrarsi, recuperare le password o accedere tramite email perché l’invio della digest settimanale è partito dopo una migrazione del forum legacy e c’erano oltre 300.000 email nella coda sidekiq; quindi chiunque provasse ad accedere tramite email, registrarsi, recuperare la password, ecc. non riceveva alcuna email ed era bloccato (come si dice)..

Il problema era dovuto al fatto che utilizziamo GMAIL come relay postale e GMAIL (versione gratuita) impone limiti su questo tipo di relay SMTP, quindi GMAIL ci ha bloccato per il giorno.

Vorrei richiedere questa funzionalità in futuro (a meno che non esista un altro modo per risolvere il problema).

Proposta

Aggiungere un’altra serie di variabili app.yml che consentano agli amministratori di configurare un relay email diverso per le digest.

Durante il processo di configurazione, la finestra di dialogo potrebbe aggiungere la domanda: Vuoi configurare un server SMTP diverso per le digest? e l’utente potrebbe utilizzare lo stesso relay SMTP se lo desidera.

Motivazione

Per i forum di grandi dimensioni con molte attività di invio di digest, sarebbe utile avere l’opzione di inoltrare queste email di digest tramite un relay SMTP diverso da quello utilizzato per le attività chiave, come il recupero della password, l’accesso e la registrazione.

Per ora, abbiamo disattivato tutte le digest. Abbiamo notato una possibilità per limitare questo tramite l’impostazione “ultimi X giorni”. Il valore predefinito, quando l’ho controllato oggi, era di 365 giorni. Per qualche motivo, il nostro server migrato ha messo in coda oltre 300.000 messaggi.

Discussione

Non è un problema enorme, ma penso che sarebbe utile separare le email digest da quelle critiche, perché anche se la priorità di coda è più alta per le email critiche, se il relay SMTP viene bloccato a causa di un numero eccessivo di digest, anche le email critiche verranno bloccate.

Inoltre, alcuni forum potrebbero trovarsi in una situazione simile senza rendersi conto del motivo per cui la loro email SMTP non funziona; quando in realtà è stata bloccata per il motivo sopra menzionato.

Grazie per la vostra attenta considerazione.

TangentialDuck

2 Mi Piace
2

Si prega di notare che l’uso di Gmail gratuito per inviare email da Discourse non è supportato. Si tratta nuovamente dei termini di servizio di Google. Utilizzare Gmail in questo modo equivale a una #installazione-non-supportata.

È difficile vedere come abbia senso implementare questa richiesta di funzionalità; se aveste utilizzato un meccanismo di invio email supportato, l’incidente non sarebbe potuto verificarsi.

3

Questo non è vero.

Abbiamo un dominio Google e la posta elettronica gratuita è stata supportata per molti anni ed è supportata attualmente.

Cerca di essere più comprensivo dopo aver gestito un forum per 20 anni… Non siamo appena usciti da un uovo ieri, @Stephen

1 Mi Piace
4

Assolutamente sì, le community che ignorano la nostra guida sulle email si trovano spesso in questa situazione.

Google non consente l’invio di email transazionali da account Gmail e abbiamo visto community perdere i propri account in modo permanente nel tentativo di farlo. Anche gli account GSuite a pagamento hanno limiti rigidi sul numero di email transazionali inviate ogni giorno. Non sei la prima persona a trovarsi in questa situazione e non possiamo aiutarti a aggirare le condizioni imposte da Google.

1 Mi Piace
5

Mi sono appena collegato al nostro account GSuite e ho controllato i Termini di servizio; ciò che state dicendo non è vero:

@Stephen, sei troppo frettoloso nel prendere decisioni. Non ho chiesto una funzionalità per “eludere i Termini di servizio di Google”, quindi ti prego di non attribuire parole alle mie risposte.

Sei troppo frettoloso nel prendere decisioni e accusi falsamente le persone, @Steven. Forse è meglio lasciare che altri rispondano alle mie richieste, chi non è così impulsivo?

6

C’è una certa incoerenza in quello che stai dicendo qui:

Gmail non è G-Suite. Gli account G-Suite a pagamento hanno i seguenti limiti:

Tipo di limite Limite
Messaggi al giorno
Limite di invio giornaliero* 2.000 (500 per gli account di prova)

Gli account Gmail gratuiti hanno sempre il limite di 500 email.

Quello sono i Termini di Servizio di Google, non c’entrano nulla con quanto sopra. C’è sicuramente una differenza tra “ha funzionato fino a ora” ed essere autorizzati a farlo. Abbiamo visto utenti tentare questa cosa negli ultimi sette anni e non è mai andata a buon fine:

Altre letture sull'argomento

New setup - errors when trying to send emails through gmail - #2 by pfaffman
Office 365 SMTP settings - #2 by codinghorror
https://meta.discourse.org/t/setup-smtp-in-discourse/79173/2
Anyone using gmail for SMTP? - #8 by sam
Gmail SMTP Relay Setup not working - #2 by justin
Can I use gmail smtp? - #2 by fefrei
POP3 polling error - #4 by pfaffman
Sidekiq queue too large - Google email provider problems - #2 by codinghorror

C’è una guida alla configurazione della posta con un elenco di provider consigliati. Non sei obbligato a seguirla, ma non possiamo aiutarti a usare Gmail o GSuite in modi non previsti.

1 Mi Piace
7

Sì, lo sapevo tutto questo prima di scrivere, @Steven.

Dovresti davvero evitare di sottovalutare la conoscenza di qualcuno che è online da prima dell’esistenza del browser Mosaic, a mio avviso, e fare attenzione a come rispondi. Non togliere il divertimento di Discourse e della tecnologia in generale facendo accuse verso gli altri.

Prima mi hai detto che “NON esiste un Gmail gratuito” (cosa che sapevo essere errata) e mi hai accusato di attività malevole, poi hai fatto i tuoi compiti e hai scoperto che GSuite ha un limite di 2.500 al giorno, cosa che conosco da molto tempo dato che amministro questo account GSuite da anni.

Dovresti scusarti quando agisci con troppa fretta, inizi ad accusare le persone di cose negative e ti sbagli sui dettagli.

Non è affatto divertente pubblicare una semplice richiesta di funzionalità e dover rispondere a questa energia negativa.

8

Questo suggerisce che stai utilizzando Gmail e non G Suite, il che è contro le regole. Molte persone, in particolare quelle che non conoscono l’amministrazione di sistema, tentano di usare Gmail, ma ciò viola i termini di servizio. Spiegare questo agli utenti è un’idea buona e non è né maleducato né scortese.

Tuttavia, stai utilizzando G Suite, il che è perfettamente accettabile. Dalla tua pubblicazione originale non era possibile capirlo. Ecco perché sembra che tu stia venendo trattato in modo così ingiusto.

Fatta eccezione per il fatto che G Suite in realtà non funziona bene su un forum con molto traffico, come descrivi. Stai chiedendo una nuova funzionalità affinché Discourse possa in qualche modo funzionare con un servizio di posta che ti limita a 2500 messaggi al giorno.

È possibile, anche se non molto semplice, creare un plugin per farlo. Sospetto che richieda diversi giorni di lavoro a qualcuno familiare con lo sviluppo di Discourse.

La soluzione è utilizzare un servizio di posta in grado di gestire la quantità di email che devi inviare.

2 Mi Piace
9

Solo per fare un aggiornamento: questo argomento è un duplicato. La richiesta di più servizi SMTP è stata già avanzata in precedenza:

Il caso d’uso qui è leggermente diverso, ma il problema è nato da una configurazione errata delle email di riepilogo. Unix.com ha 138.062 utenti; un limite di 2.000 email al giorno, anche per attività critiche come il reset delle password, permetterebbe a solo l’1,8% di tali utenti di interagire su base giornaliera.

Modifica: corretto da 2.500 a 2.000, per riflettere il limite effettivo.

1 Mi Piace
10

È proprio per questo, @pfaffman, che è meglio per tutti online non essere troppo veloci nel fare affermazioni accusatorie verso gli altri riguardo alla tecnologia e/o alle loro motivazioni. Di solito, dovremmo fare domande prima di premere il grilletto e iniziare a sparare, LOL.

Sì, ho scritto GMAIL invece di GSUITE, ma quando ho creato questo dominio decenni fa non esisteva ancora GSUITE e si chiamava semplicemente GMAIL. Inoltre, il motivo per cui non ho usato termini precisi è che la mia richiesta di funzionalità NON HA NULLA A CHE FARE CON GMAIL. Quella è una discussione completamente laterale.

Se volessi (o tu volessi), potremmo andare su qualsiasi server, come molti qui possono fare, e digitare apt install postfix o apt install sendmail; in 15 minuti o meno potremmo avere il nostro relay SMTP attivo e funzionante.

Per favore, non cambiamo argomento passando da un processo di digest a una discussione su GMail vs GSuite vs Blah Blah. apt install postfix è banale.

Il problema è quello dell’affidabilità. Sono concetti base da 101.

Eseguire email critiche per la missione sullo stesso relay SMTP dei digest non è come vorrei gestire le cose, quindi ho fatto questa richiesta di funzionalità.

Restiamo, per favore, in tema riguardo a ciò che sto chiedendo, dato che so bene di cosa sto parlando quando si tratta di costruire app critiche per la missione.

Ecco di nuovo:

Non voglio che le mie email critiche per la missione siano sullo stesso relay SMTP delle email di digest e penso che sia una buona idea e renda il sistema più robusto.

Lasciamo perdere la discussione molto laterale su GMAIL o GSuite o MonkeyMail… bla bla. Mi dispiace di averlo anche solo menzionato, perché il server di posta non è pertinente alla mia richiesta di funzionalità.

Rallentiamo. Siate gentili con gli altri… Se qualcuno pubblica qualcosa e non capisci qualcosa o ti senti confuso, allora chiedi; non sparare alle persone @Steven.

Posso costruire un relay SMTP in 10 minuti. Possiamo tutti farlo. apt install postfix fatto… Se voglio usare GSuite o postfix o donkey kong mail, dipende da me, non dagli altri. Come ho detto…

Il punto principale… (di nuovo)

È più affidabile avere le email critiche per la missione su un server diverso rispetto a un canale di digest. Sono cose di base per un server molto trafficato.

apt install postfix crea un relay SMTP. Sto richiedendo una funzionalità che permetta alle email critiche per la missione (reset password, email di registrazione, login via email) di essere su un canale diverso rispetto ai digest per motivi di affidabilità e prestazioni.

11

@Steven

Non è questo il punto. È un discorso laterale.

Nota a margine: in realtà, avevamo oltre 500.000 utenti, ma li ho eliminati :slight_smile:

Sto parlando di avere l’email critica su un canale diverso (SMTP relay) rispetto al traffico dei digest.

Sicuramente, questo semplice concetto è molto facile da capire: perché due canali sono meglio?

Questa discussione sta deviando completamente dall’idea originale alla base della mia richiesta di funzionalità.

Mi dispiace di aver anche solo postato e chiesto… :frowning:

A mio avviso, questa discussione successiva al mio post originale è stata molto fuori tema.

12

Non dovresti sottovalutare nessuna delle persone che stanno cercando di aiutarti. Nessuno è contro di te.

3 Mi Piace
13

Questo è il mio ultimo post su questo argomento.

Per quanto riguarda GSuite (che non è affatto il punto della mia richiesta di funzionalità)

  • Il numero massimo di messaggi che un utente può inviare in un periodo di 24 ore è 10.000. Tuttavia, questo può variare in base al numero di licenze utente nel tuo account G Suite.
  • Un utente G Suite registrato non può inoltrare messaggi a più di 10.000 destinatari unici in un periodo di 24 ore.

Rif: Route outgoing SMTP relay messages through Google  |  Set up & manage services  |  Google Workspace Help

Tuttavia, questo è completamente fuori tema per me; perché anche se GSuite permettesse 1000M+ email al giorno tramite relay SMTP, vorrei comunque un canale relay SMTP diverso per le email mission critical rispetto alle email digest.

Questo è il punto.

Grazie. Si prega di prendere in considerazione questa richiesta in un futuro aggiornamento. Penso che sia relativamente semplice da implementare.

Questa richiesta di funzionalità non riguarda la personalità né i meriti o i dettagli dei provider di posta elettronica.

La mia richiesta di funzionalità riguarda l’affidabilità e il mantenere le email mission critical fuori dal canale digest.

Fine trasmissione… :slight_smile:

14

Gli sviluppatori di Discourse hanno sistemi di posta che funzionano. Non aggiungeranno una funzionalità per chi desidera utilizzare più sistemi di posta inaffidabili. Se lo desideri, puoi sviluppare un plugin. Sarà difficile da realizzare e problematico da mantenere.

Potrebbe essere facile installare Postfix, ma gestire un server di posta funzionante oggi è molto più complesso rispetto a quando ho portato Sendmail e uucp su Linux. Se gestire un server di posta fosse semplice, avresti già un server di posta funzionante e non ne vorresti due.

Non è questo il mio punto di vista, ma potresti saperne molto di più dello sviluppo di plugin per Discourse rispetto a me.

3 Mi Piace
15

Un semplice workaround è semplicemente “disabilitare” le email di digest a livello globale se causano così tanti problemi. I suggerimenti migliori potrebbero essere già stati fatti; posso solo suggerire di utilizzare un provider di posta che non imponga limiti, ad esempio Mailgun. In questo modo, tutti saranno felici (a meno che non abbiate vincoli che vi limitano all’uso di un particolare provider di posta per qualche motivo).

4 Mi Piace
16

Concordo, c’è molta incoerenza in ciò che @neounix ha pubblicato inizialmente e molti dettagli cambiano nelle risposte successive.

Ho messo in evidenza quanto sopra: le restrizioni degli account gratuiti sono già documentate altrove in questo argomento. Gli account G Suite ‘gratuiti’ ereditati hanno questi limiti. Se si tratta di un account GSuite a pagamento, il commento sopra è fuorviante e spiega la mia risposta.

Ancora una volta non sei chiaro su quale servizio stai utilizzando qui; se si tratta delle vecchie Google Apps nel piano gratuito, allora sei limitato a 500 destinatari al giorno per utente, lo stesso del prodotto Gmail gratuito. Se stai utilizzando un account GSuite a pagamento, dovresti usare il servizio di relay SMTP di Google; i limiti sono 10.000 al giorno per utente, meglio ma comunque non ottimi, specialmente con oltre 130.000 utenti che devono richiedere il reimpostazione della password. È ottimo sentire che hai eliminato alcuni utenti durante la migrazione, anche se non sono sicuro di quanto ciò sia realmente rilevante.

Capisco che tu sia frustrato in questa situazione; i tuoi test non hanno intercettato i digest che sarebbero stati messi in coda. Ciò ha causato un periodo di effettiva indisponibilità per chiunque tentasse di reimpostare la password e accedere nuovamente ai propri account.

Alcune volte sopra hai suggerito che io attribuisca parole alle tue risposte, ma da quanto vedo le tue risposte sono in linea con le informazioni che hai fornito. Mi scuso se non sei d’accordo, ma rileggendo i post è ancora poco chiaro esattamente quale prodotto stai utilizzando.

A proposito, sono @Stephen, non @Steven - stai taggando e notificando un utente completamente diverso.

3 Mi Piace
17

Se è così, sentiti libero di finanziarlo pubblicando nel canale Marketplace con un budget indicato. Ci sono anche alcuni ottimi suggerimenti qui sopra :index_pointing_up: per ridurre il volume delle email: ti consiglio di sfruttarli.

3 Mi Piace
18

Per ora, abbiamo deciso di disattivare completamente i digest; ecco il contesto aggiornato:

Abbiamo anche un server di staging e, poiché Discourse abilita di default i digest settimanali (con una finestra di 365 giorni) “out-of-the-box” all’installazione, anche il server di staging ha avviato un digest lo scorso weekend (cosa che non aspettavamo), LOL.

Quindi, prima di sapere che ciò sarebbe potuto accadere… ho provato a eseguire un backup sul server di staging e il sistema ha rifiutato, restituendo un errore. Ho dimenticato il messaggio esatto nella console di amministrazione, ma ricordo che c’era un indizio che puntava alla coda delle email.

Con quell’indizio, guardando ora a sidekiq - e effettivamente c’erano oltre 300.000 messaggi di digest in coda, a causa della configurazione predefinita dei digest impostata su “attivo” e “ultimi 365 giorni”.

Quindi, ho svuotato la coda delle email dalla riga di comando, sono tornato al pannello di amministrazione dei backup e il backup ha funzionato perfettamente.

Poiché il sistema email di Discourse si basa su sidekiq, questo deve essere il motivo per cui configurare canali diversi (server email diversi) per messaggi critici e digest potrebbe essere complicato. Vedo che non è così semplice come pensavo inizialmente (basterebbe configurare due server email negli ambienti).

Ecco la parte divertente… LOL

All’inizio ho pensato che sarebbe stata una buona idea disabilitare i digest di default OOTB invece di averli abilitati con una finestra di accesso di 365 giorni; ma poi ho ricordato che l’errore era tutto mio; e non era una buona idea pubblicarlo su meta, LOL.

Quando Discourse è stato installato, ha impostato tutti gli utenti migrati (dal nostro vecchio forum vB3), di default, con last_seen_at circa 50 anni fa.

Sono entrato nel database e ho modificato manualmente tutti gli utenti impostando “ultimo accesso” a 10 giorni fa! LOL. Non avevo idea, all’epoca, della configurazione dei digest; e pensavo che fosse un errore di migrazione avere tutti gli utenti con “ultimo accesso” a 50 anni fa dopo la migrazione. Haha… mi sbagliavo. C’è un buon motivo per questo.

Discourse ha avviato un massiccio processo di digest settimanale che ha sovraccaricato sidekiq sia sui nostri server di produzione che di staging; perché ho applicato l’hack del DB “ultimo accesso 10 giorni fa” sul server di staging e l’ho esportato in produzione. Questo è stato l’errore che ha causato questo problema.

Poiché la maggior parte delle persone non entra in postgres e fa cose come me, ad esempio:

UPDATE users SET last_seen_at = 'oggi meno 10 giorni'

… su una migrazione legacy con molti utenti…

non avranno questo tipo di problema massiccio con i digest.

LOL

Mi scuso per aver creato tutta questa tensione a causa del mio hack UPDATE sulla tabella users.

Tuttavia, ritengo ragionevole avere l’email critica e l’email digest su due server email diversi, ma guardando sidekiq non è ancora chiaro per me se esista un modo semplice per farlo, poiché non ho ancora esperienza con sidekiq.

Tuttavia, posso consigliare a chi esegue migrazioni: se state migrando un forum verso Discourse (che è un’ottima idea), lasciate last_seen_at di default nella tabella users così com’è :slight_smile:

1 Mi Piace
19

Di solito consiglierei di posizionare Mailhog tra un’istanza di staging e il mondo esterno. È eccellente in questo tipo di scenario.

4 Mi Piace
20

Aggiungerò DISCOURSE_DISABLE_DIGEST_EMAILS alle mie istanze di staging. Ma con gli email disabilitati impostati su non staff, non è un grosso problema.

2 Mi Piace