È possibile ottimizzare il periodo di digest per migliaia di community? Ogni lunedì Discourse invia diverse migliaia di email in 1-2 secondi, il che causa problemi di SPAM con il nostro server di posta personalizzato.
Come si può resettare “last_digest_time” per account e normalizzarlo per gli altri mille account?
L’obiettivo è avere 100-200 digest al giorno invece di 5K il lunedì. Usiamo Discourse da 4 anni; forse c’è un problema con un aggiornamento che eseguiamo molto spesso all’ultima release.
Inoltre, forse c’è un suggerimento su come accedere a PostgreSQL dell’immagine Docker e dove “aggiornare” i record nel DB.
Quali sono le tue idee? Il server invia semplicemente le email alle destinazioni, dove vengono inserite nello SPAM. Io farei lo stesso se qualcuno mi inviasse 2.000 email in 1 secondo.
Se stai ospitando il tuo stesso server SMTP, stai incorrendo nei soliti problemi associati. Le aziende di consegna email come Mailgun e SendGrid utilizzano diverse tecniche per garantire che i loro server siano considerati attendibili e affidabili dalle reti di destinazione. Ecco perché la documentazione consiglia di utilizzare uno di questi prodotti piuttosto che l’hosting autonomo.
Esatto: anche se invii quei messaggi solo in picchi, i servizi di invio email di terze parti affidabili possono consegnare in modo affidabile centinaia di migliaia di email nelle caselle di posta di terze parti ogni ora.
Purtroppo non possiamo offrire alcun supporto se insistete nell’eseguire il vostro stesso server di posta. Se decidete di non seguire le raccomandazioni, accettate la maggiore complessità che questo comporta.
Tutto funziona correttamente con SMTP, inclusi DMARC, SPF e DKIM. Utilizzo il mio stesso server SMTP dal 2005. All’epoca non esistevano servizi inutili di tipo “macchina da soldi”. Immaginiamo che domani qualcuno provi a far pagare l’aria…
Quindi, torniamo al problema. So che il modo più semplice per un Senior Tester è indirizzarmi da qualche parte o verso qualche servizio a pagamento. Qualcuno potrebbe aiutarmi a risolvere un bug critico in Discourse? Non sono ancora d’accordo sul fatto che Discourse debba inviare 10.000 email in un secondo. Dovrebbe esserci un servizio di rotazione o qualcosa di simile che normalizzi “last_digest_timestamp” tra gli account.
Non sono dipendente della CDCK e non ho alcun interesse finanziario nel indirizzarvi verso servizi di terze parti.
Se non desiderate seguire la raccomandazione e la documentazione, la decisione è vostra. In questo caso, vi allontanate dal percorso del supporto gratuito che offriamo qui alla comunità, quindi l’unica altra opzione è rivolgersi a un consulente tramite il Marketplace.
Questo non è un problema di Discourse; la questione dipende dal fatto che l’indirizzo IP del vostro server di posta non è considerato affidabile. Non possiamo aiutarvi a risolvere questo problema e voi rifiutate di considerare le opzioni esistenti a tale scopo.
Sì, lavoro con comunità che inviano dieci volte quel volume; molte delle persone che gestiscono grandi comunità operano a quella scala o anche di più.
Le tue esigenze in materia di email sembrano ora superare le tue competenze sul protocollo per garantire una consegna affidabile di email in grandi volumi; è per questo motivo che esistono aziende specializzate in email transazionali. Nessuno qui sta facendo pubblicità a ‘big email’ – si tratta semplicemente della sfida di consegnare email ad alto volume.
Il tuo server di posta può trattenere i messaggi e distribuirne la consegna nel tempo. Questo è davvero un problema del tuo server di posta, non di Discourse. Ho gestito server di posta dall’inizio degli anni '90 fino al 2005, quando lo spam ha reso tutto troppo difficile. Oggi è ancora più complicato.
Ho alcuni limiti di velocità. Anche se non lo fai, i server SMTP tipici hanno impostazioni preconfigurate per te. I server di posta sono più intelligenti oggi e possono rilevare facilmente il tuo ritardo tra le email.
Sì, perché utilizzano il servizio che hai menzionato prima. Ancora non capisci la differenza tra quei servizi e il servizio SMTP personale. Loro usano un enorme pool di indirizzi IP e simulano diversi mittenti. Questa è una buona tecnica per le aziende che fanno “hard” SPAM. Ovviamente, pagheranno per questo servizio.
Non vedo un motivo per cui le persone dovrebbero usare queste “macchine da soldi” per Discourse se Discourse non invia SPAM. Ops… scusa… a causa di un bug, potrebbe inviare 100K email lunedì in 1 secondo perché @Stephensays dice che questo è un comportamento VERO.
Ok, non vedo senso chiacchierare con persone che hanno una Corona sopra la testa. Sì, Discourse è fantastico e grazie mille per il tuo contributo.
Spero che le persone semplici senza avranno alcune idee qui.
Secondo le risposte fornite sopra dal team di Discourse, non rilevano alcun problema con Discourse. Ho risolto questo problema in modo approssimativo intervenendo direttamente sul database. Ecco la mia soluzione
cd /var/discourse
./launcher enter app
rails c
Topic.exec_sql("UPDATE users SET last_emailed_at = now() + interval '30' second * id WHERE last_emailed_at > ('2020-03-14'::date) AND last_emailed_at < ('2020-03-17'::date)")
Aggiornare l’intervallo di last_emailed_at nella query SQL. Avevo 4K valori di last_emailed_at in un giorno, il 16 marzo. Quindi, ora tutti gli utenti sono stati ottimizzati per un periodo di 3 giorni con un intervallo di 30 secondi.
Discourse non è progettato per essere utilizzato con un servizio SMTP personale. Mi dispiace se non è stato spiegato chiaramente; può certamente funzionare, ma per una community con un’attività email regolare non è una buona idea. Questa è una limitazione dello stato attuale della posta elettronica e tutti stiamo reagendo come possiamo.
sopra la testa. Sì, Discourse è fantastico e grazie mille per il tuo contributo.