É possível otimizar o período de resumo por milhares de comunidades? Toda segunda-feira, o Discourse envia algumas milhares de e-mails em 1-2 segundos, o que causa problemas de SPAM com nosso servidor de e-mail personalizado.
Como redefinir o “last_digest_time” por conta e normalizá-lo para as outras milhares de contas?
O objetivo é ter de 100 a 200 resumos por dia, em vez de 5 mil na segunda-feira. Temos usado o Discourse nos últimos 4 anos; talvez haja um problema com uma atualização que fazemos frequentemente para a versão mais recente.
Além disso, talvez haja uma dica sobre como acessar o PostgreSQL da imagem Docker e onde “atualizar” os registros no banco de dados.
Quais são suas ideias? O servidor apenas envia mensagens para os destinos onde colocam nossa mensagem em SPAM. Eu faria o mesmo se alguém me enviasse 2 mil mensagens em 1 segundo.
Se você estiver hospedando seu próprio SMTP, estará caindo nas armadilhas habituais associadas a isso. Empresas de entrega de e-mail, como Mailgun e SendGrid, utilizam diversas técnicas para garantir que seus servidores sejam confiáveis e considerados reputados pelas redes de destino. É por isso que a documentação recomenda o uso de um desses produtos em vez de auto-hospedagem.
Exatamente — embora você envie essas mensagens apenas em picos, serviços de correio de terceiros reputados podem entregar com confiabilidade centenas de milhares de e-mails em caixas de entrada de terceiros a cada hora.
Infelizmente, não podemos oferecer qualquer assistência se você insistir em operar seu próprio servidor de e-mail. Se decidir não seguir as recomendações, você aceita a complexidade adicional que isso gera.
Tudo está correto com o SMTP, incluindo DMARC, SPF e DKIM. Uso meu próprio servidor SMTP desde 2005. Naquela época, não existiam serviços inúteis de “máquina de dinheiro”. Vamos imaginar que, amanhã, alguém tente cobrar pelo ar…
Portanto, vamos voltar ao problema. Sei que a maneira mais fácil para um Tester Sênior é me redirecionar para algum serviço pago. Alguém poderia me ajudar a corrigir um bug crítico no Discourse? Ainda não concordo que o Discourse deva enviar 10 mil e-mails em 1 segundo. Deveria haver um serviço de rotação ou algo similar que normalize o “last_digest_timestamp” entre as contas.
Eu não sou empregado pela CDCK, nem tenho qualquer interesse financeiro em indicar-lhe serviços de terceiros.
Se você não quiser seguir a recomendação e a documentação, essa é sua decisão. Nesse caso, isso o leva para fora do caminho do suporte gratuito que oferecemos aqui à comunidade, então sua única outra opção é se engajar com um consultor através do Marketplace.
Isso não é um problema do Discourse; essa questão deve-se ao fato de que o IP do seu servidor de correio não é considerado confiável. Não podemos ajudá-lo a corrigir isso e você se recusa a considerar as opções que existem para esse fim.
Sim, trabalho com comunidades que enviam dez vezes esse volume; muitas das pessoas que gerenciam comunidades grandes operam nessa escala ou em escalas ainda maiores.
Parece que suas necessidades de e-mail agora superam sua familiaridade com o protocolo para garantir a entrega confiável de e-mail em grande volume. É por isso que existem empresas de e-mail transacional. Ninguém aqui está fazendo propaganda de ‘e-mail em massa’ — o desafio é simplesmente entregar e-mail de alto volume de forma eficaz.
Você pode fazer com que seu servidor de correio retenha as mensagens e distribua a entrega de forma escalonada. Isso é realmente uma questão do seu servidor de correio, e não do Discourse. Eu gerenciei servidores de correio desde o início dos anos 1990 até por volta de 2005, quando o spam tornou tudo muito difícil. Hoje em dia, é muito mais difícil.
Tenho alguns limites de taxa. Se você nem sequer fizer isso, os servidores SMTP típicos já possuem configurações pré-definidas para você. Os servidores de e-mail são mais inteligentes hoje e conseguem detectar facilmente o seu atraso entre as mensagens.
Sim, porque eles utilizam o serviço que você mencionou anteriormente. Você ainda não entende a diferença entre esses serviços e o serviço SMTP pessoal. Eles usam um enorme conjunto de IPs e simulam diferentes remetentes. Essa é uma boa técnica para empresas que fazem SPAM “agressivo”. Claro, eles pagam por esse serviço.
Não vejo motivo para que as pessoas devam usar essas “máquinas de dinheiro” para o Discourse, já que o Discourse não envia SPAM. Ops… desculpe… devido a um bug, ele pode enviar 100 mil mensagens em 1 segundo na segunda-feira, porque o @Stephen diz que esse é o comportamento REAL.
Ok, não vejo sentido em conversar com pessoas que têm uma coroa no topo da cabeça. Sim, o Discourse é legal e muito obrigado pela sua contribuição.
Espero que pessoas simples, sem , tenham algumas ideias aqui.
De acordo com as respostas acima da equipe do Discourse, eles não veem nenhum problema com o Discourse. Resolvi esse problema de forma suja, com uma manipulação direta do banco de dados. Aqui está minha solução
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)")
Atualize o intervalo de last_emailed_at na consulta SQL. Eu tinha 4 mil registros de last_emailed_at em um dia, no dia 16 de março. Assim, agora todos os usuários foram otimizados para um período de 3 dias com um intervalo de 30 segundos.
O Discourse não foi projetado para ser usado com um serviço SMTP pessoal. Desculpe se isso não foi explicado claramente; ele certamente pode funcionar, mas para uma comunidade com atividade regular de e-mail, não é uma boa ideia. Esta é uma limitação do estado atual do e-mail, e todos nós estamos reagindo da melhor forma possível.
no topo da cabeça. Sim, o Discourse é legal e muito obrigado pela sua contribuição.