Solicitações de recursos: Conta de e-mail separada para resumos

Contribuir Funcionalidade
1

De um novato: hoje tivemos uma experiência em que praticamente todos os nossos e-mails foram desligados, e os usuários não conseguiam se registrar, recuperar senhas ou fazer login por e-mail. Isso ocorreu porque o resumo semanal foi acionado após uma migração de fórum legado, e havia mais de 300 mil e-mails na fila do sidekiq. Assim, qualquer pessoa que tentasse fazer login por e-mail, se registrar ou recuperar a senha, etc., não recebia nenhum e-mail e ficava sem saída (como dizem)..

O problema ocorreu porque usamos o GMAIL como nosso servidor de retransmissão de e-mail, e o GMAIL (gratuito) impõe limites nesse tipo de retransmissão SMTP, o que levou o GMAIL a bloquear nosso serviço por um dia.

Gostaria de solicitar essa funcionalidade no futuro (a menos que haja outra forma de resolver isso).

Proposta

Adicionar um novo conjunto de variáveis no app.yml que permitam aos administradores configurar um servidor de retransmissão de e-mail diferente para os resumos semanais.

Durante o processo de configuração, o diálogo poderia incluir a pergunta: Deseja configurar um servidor SMTP diferente para os resumos semanais?, e o usuário poderia usar o mesmo servidor de retransmissão SMTP, se desejasse.

Justificativa

Para fóruns grandes com muita atividade de resumos semanais, seria útil ter a opção de retransmitir esses e-mails de resumo por meio de um servidor SMTP diferente daquele usado para tarefas essenciais, como recuperação de senha, login e registro.

Por enquanto, desativamos todos os resumos semanais. Vimos uma opção para limitar isso com base nos últimos X dias. O padrão, quando verifiquei hoje, era de 365 dias. Por algum motivo, nosso servidor migrado enfileirou mais de 300 mil mensagens.

Discussão

Não é um grande problema, mas seria bom, na minha opinião, separar os e-mails de resumo semanal dos e-mails críticos. Pois mesmo que a prioridade de fila seja maior para os e-mails críticos, se o servidor de retransmissão SMTP for bloqueado devido a um número excessivo de resumos, os e-mails críticos também serão bloqueados.

Além disso, alguns fóruns podem estar passando por uma situação semelhante sem saber por que seu envio de e-mails SMTP não está funcionando; quando, na verdade, foi bloqueado pelo motivo mencionado.

Obrigado pela sua atenção e consideração.

TangentialDuck

2 curtidas
2

Por favor, note que o uso do Gmail gratuito para enviar qualquer e-mail a partir do Discourse não é suportado. Novamente, isso se deve aos termos de serviço do Google. Usar o Gmail dessa forma beira uma #instalação-nao-suportada.

É difícil ver como essa solicitação de recurso faria sentido para implementação; se você tivesse usado um mecanismo de e-mail suportado, o incidente não teria ocorrido.

3

Isso não é verdade.

Temos um domínio do Google e o e-mail gratuito tem sido suportado há muitos anos e continua sendo suportado agora.

Tente me dar um pouco de folga depois de gerenciar um fórum por 20 anos… Não acabamos de sair de um ovo ontem, @Stephen

1 curtida
4

Isso é absolutamente verdade. Comunidades que ignoram nosso guia de e-mail esbarram nisso o tempo todo.

O Google não permite que nenhum e-mail transacional seja enviado a partir de contas do Gmail, e já vimos comunidades perderem contas permanentemente ao tentar fazer isso. Contas pagas do GSuite também têm limites rígidos para e-mails transacionais por dia. Você não é a primeira pessoa a se encontrar nessa situação e não podemos ajudá-la a contornar os termos implementados pelo Google.

1 curtida
5

Acabei de fazer login na nossa conta do GSuite e verifiquei os Termos de Serviço (TOS). O que você está dizendo não é verdade:

@Stephen, você está muito rápido para tomar decisões precipitadas. Eu não pedi um recurso para “contornar os TOS do Google”, então, por favor, pare de atribuir palavras às minhas postagens.

Você está muito rápido para tomar decisões precipitadas e acusar falsamente as pessoas, @Steven. Talvez seja melhor deixar que outros respondam às minhas solicitações, aqueles que não são tão impulsivos?

6

Há uma inconsistência no que você está dizendo aqui:

O Gmail não é o G-Suite. Contas pagas do G-Suite têm os seguintes limites:

Tipo de limite Limite
Mensagens por dia
Limite de envio diário* 2.000 (500 para contas de teste)

Contas gratuitas do Gmail sempre têm o limite de 500 e-mails.

Esse é o Termo de Uso do Google, não tem nada a ver com o assunto acima. Há, sem dúvida, uma diferença entre “funcionou até agora” e ter permissão para fazer isso. Nos últimos sete anos, vimos usuários tentarem isso e nunca funcionou:

Mais leituras sobre o tema

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

Existe um guia de configuração de e-mail com uma lista de provedores recomendados. Você não é obrigado a segui-lo, mas não podemos ajudá-lo a usar o Gmail ou o GSuite de maneiras não previstas.

1 curtida
7

Sim, eu já sabia de tudo isso antes de postar, @Steven.

Você realmente deveria se abster de subestimar o conhecimento de alguém que está online desde antes do navegador Mosaic existir, na minha opinião, e ter cuidado com a forma como responde. Não estrague a diversão do Discourse e da tecnologia em geral fazendo declarações acusatórias contra os outros.

Primeiro, você me disse que “NÃO existe GMAIL gratuito” (o que eu sabia estar errado) e me acusou de alguma atividade maliciosa. Depois, você fez sua lição de casa e descobriu que o GSuite tem um limite de 2.500 por dia, algo que eu já sabia há muito tempo, já que administro essa conta do GSuite há anos.

Você deveria se desculpar quando age com tanta rapidez, começa a acusar as pessoas de coisas ruins e está errado nos detalhes.

Não é nada divertido, de verdade, fazer um pedido de recurso simples e ter que responder a essa energia negativa.

8

Isso sugere que você está usando o Gmail e não o Gsuite, o que vai contra as regras. Muitas pessoas, especialmente aquelas que não sabem o que é administração de sistemas, tentam usar o Gmail, e isso viola os termos de serviço. Informar as pessoas sobre isso é uma boa ideia e não é malvado ou rude.

Mas você está usando o Gsuite, o que é perfeitamente aceitável. Isso era impossível de perceber na sua postagem original. É por isso que parece que você está sendo tratado de forma tão injusta.

Exceto que o Gsuite realmente não funciona em um fórum com muito tráfego, como você descreveu. Você está pedindo um novo recurso para que o Discourse funcione de alguma forma com um serviço de e-mail que limita você a 2500 mensagens por dia.

É possível, mas não será muito fácil, criar um plugin para fazer isso. Suspeito que levaria vários dias de trabalho para alguém familiarizado com o desenvolvimento do Discourse.

A solução é usar um serviço de e-mail que consiga entregar a quantidade de e-mails que você precisa enviar.

2 curtidas
9

Só para dar um retorno: este tópico é uma duplicata. A solicitação de múltiplos serviços SMTP já foi feita anteriormente:

O caso de uso aqui é um pouco diferente, mas o problema surgiu de uma configuração incorreta do resumo. O Unix.com tem 138.062 usuários; um limite de 2.000 e-mails por dia, mesmo para coisas críticas como redefinição de senha, permitiria que apenas 1,8% desses usuários interagissem diariamente.

edit: corrigido de 2500 para 2000, para refletir o limite real

1 curtida
10

É por isso, @pfaffman, que é melhor para todos online não serem rápidos em fazer declarações acusatórias contra outros em relação à tecnologia e/ou às suas motivações. Normalmente, deveríamos fazer perguntas antes de puxar o gatilho e começar a atirar, kkkk.

Sim, eu disse GMAIL em vez de GSUITE, mas quando criei este domínio décadas atrás, não existia GSUITE e era chamado apenas de GMAIL. Além disso, a razão pela qual não usei precisão é porque minha solicitação de recurso não tem NADA a ver com o GMAIL. Essa é uma discussão completamente tangencial.

Se eu quisesse (ou você quisesse), poderíamos ir a qualquer servidor, como muitos aqui podem fazer, e digitar apt install postfix ou apt install sendmail, e em 15 minutos ou menos teríamos nosso próprio relay SMTP em funcionamento.

Por favor, não vamos mudar o assunto de mover o tráfego pesado de um processo de resumo para uma discussão sobre GMail vs. GSuite vs. Blah Blah. apt install postfix é trivial.

O problema é de confiabilidade. São coisas básicas de nível 101.

Executar e-mail mission critical no mesmo relay SMTP que resumos não é como eu gostaria de operar as coisas, então fiz essa solicitação de recurso.

Vamos manter o foco, por favor, no que estou solicitando, já que eu realmente sei do que estou falando quando se trata de construir aplicativos mission critical.

Aqui está novamente:

Eu não quero meu e-mail mission critical no mesmo relay SMTP que o e-mail de resumo, e acho que essa é uma boa ideia e torna o sistema mais robusto.

Vamos sair da discussão muito tangencial sobre GMAIL ou GSuite ou MonkeyMail… bla bla. Sinto muito por ter mencionado isso, pois o servidor de e-mail não é relevante para minha solicitação de recurso.

Devagar. Seja gentil com os outros… Se alguém postar algo e você não entender algo ou se sentir confuso, pergunte; não atire nas pessoas @Steven.

Posso construir um relay SMTP em 10 minutos. Todos nós podemos. apt install postfix pronto… Se eu quiser usar GSuite ou postfix ou donkey kong mail, isso depende de mim, não dos outros. Como eu disse…

O Ponto Principal … (novamente)

É mais confiável ter e-mail mission critical em um servidor diferente de um canal de resumo. Isso é apenas básico para um servidor muito ocupado.

apt install postfix cria um relay SMTP. Estou solicitando um recurso que permita que e-mail mission critical (redefinição de senha, e-mail de registro, login por e-mail) esteja em um canal diferente dos resumos por motivos de confiabilidade e desempenho.

11

@Steven

Esse não é o ponto. Isso é tangencial.

Nota lateral: Na verdade, costumávamos ter mais de 500 mil usuários, mas fiz a poda deles :slight_smile:

Estou falando em ter e-mail crítico em um canal diferente (relé SMTP) do tráfego de resumos.

Certamente, esse conceito simples, e é muito fácil entender por que dois canais são melhores?

Essa discussão está se desviando muito da ideia original por trás do meu pedido de recurso.

Desculpe até ter postado e perguntado… :frowning:

Essa discussão subsequente ao meu post original tem estado muito fora do alvo, na minha opinião.

12

Você não deve subestimar nenhuma das pessoas que estão tentando ajudá-lo. Ninguém está contra você.

3 curtidas
13

Esta é minha última postagem sobre este tópico.

Sobre o assunto do GSuite (que não é de forma alguma o ponto da minha solicitação de recurso)

  • O número máximo de mensagens que um usuário pode enviar em um período de 24 horas é 10.000. No entanto, isso pode variar, dependendo do número de licenças de usuário na sua conta do G Suite.
  • Um usuário registrado do G Suite não pode retransmitir mensagens para mais de 10.000 destinatários exclusivos em um período de 24 horas.

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

No entanto, isso está totalmente fora do tópico para mim; porque mesmo que o GSuite permitisse mais de 1 bilhão de e-mails por dia via retransmissão SMTP, eu ainda gostaria de um canal de retransmissão SMTP diferente para e-mail crítico versus e-mail de resumo.

Este é o ponto.

Obrigado. Por favor, considere isso em uma atualização futura. Acredito que seja relativamente fácil adicionar isso.

Esta solicitação de recurso não trata de personalidade e também não trata dos méritos ou detalhes dos provedores de e-mail.

Minha solicitação de recurso trata de confiabilidade e de manter o e-mail crítico fora do canal de resumo.

Fim de transmissão… :slight_smile:

14

As pessoas que desenvolvem o Discourse possuem sistemas de e-mail que funcionam. Elas não vão adicionar um recurso para quem deseja usar múltiplos sistemas de e-mail não confiáveis. Você pode desenvolver um plugin se quiser. Será difícil de desenvolver e problemático de manter.

Pode ser fácil instalar o Postfix, mas é muito mais difícil operar um servidor de e-mail funcional hoje em dia do que era quando eu portei o Sendmail e o uucp para o Linux. Se operar um servidor de e-mail fosse fácil, você já teria um servidor de e-mail funcionando e não precisaria de dois.

Essa não é a minha opinião, mas você pode saber muito mais sobre desenvolvimento de plugins do Discourse do que eu.

3 curtidas
15

Uma solução simples é apenas “desativar” os e-mails de resumo globalmente, se isso estiver causando tantos problemas. As melhores sugestões podem já ter sido feitas; só posso sugerir que use um provedor de e-mail que não imponha limites, por exemplo, o Mailgun.
Dessa forma, todos ficarão satisfeitos (a menos que você tenha restrições que o limitem a usar um provedor de e-mail específico por algum motivo).

4 curtidas
16

Concordo, há muita inconsistência no que @neounix postou inicialmente, e muitos detalhes mudam nas respostas subsequentes.

O destaque acima é meu; as restrições de contas gratuitas já foram documentadas em outro lugar deste tópico. Contas “gratuitas” do G Suite herdadas têm esses limites também. Se se tratar de uma conta G Suite paga, o comentário acima é enganoso e explica minha resposta.

Novamente, você não deixa claro qual serviço está usando aqui. Se for o Google Apps legado no plano gratuito, você está limitado a 500 destinatários por dia por usuário, o mesmo que o produto Gmail gratuito. Se estiver usando uma conta G Suite paga, então você deve usar o serviço de relay SMTP do Google; os limites são de 10 mil/dia por usuário, melhor, mas ainda não ótimo, especialmente com mais de 130.000 usuários que precisam solicitar uma redefinição de senha. É ótimo saber que você eliminou alguns usuários na migração, embora não tenha certeza de como isso seja realmente relevante.

Posso entender que você esteja frustrado aqui; seus testes não detectaram os resumos que ficariam em fila. Isso causou um período de indisponibilidade efetiva para qualquer pessoa tentando redefinir senhas e recuperar o acesso às suas contas.

Algumas vezes acima você sugeriu que eu colocava palavras na sua boca, mas, pelo que vejo, as respostas estão alinhadas com as informações que você forneceu. Peço desculpas se você não concorda, mas relendo as postagens, ainda não está claro exatamente qual produto você está usando.

Por acaso, eu sou @Stephen, não @Steven — você está marcando e notificando um usuário totalmente diferente.

3 curtidas
17

Se for o caso, sinta-se à vontade para financiar a tarefa postando no Marketplace com um orçamento. Também há algumas sugestões realmente boas acima :index_pointing_up: para reduzir o volume de e-mails; sugiro aproveitá-las.

3 curtidas
18

Por enquanto, acabamos desativando completamente os resumos; e aqui está o contexto atualizado:

Temos também um servidor de staging e, como o Discourse ativa os resumos semanais (com uma janela de 365 dias) como padrão, pronto para uso ao ser instalado, esse servidor de staging também disparou um resumo no fim de semana passado (o que não esperávamos), LOL

Então, antes de saber que isso aconteceria (ou poderia acontecer)… tentei fazer um backup no servidor de staging e o sistema recusou a operação… gerando um erro. Esqueci a mensagem de erro exata no console de administração, mas lembro que havia uma pista apontando para a fila de e-mails.

Com essa pista, agora olhando para o sidekiq — e, de fato, havia mais de 300 mil mensagens de resumo na fila, devido à configuração padrão de resumo como ‘ativo’ e ‘últimos 365 dias’.

Então, limpei a fila de e-mails pela linha de comando, voltei ao painel de administração de backups e o backup funcionou perfeitamente.

Como o sistema de e-mail do Discourse é construído sobre o sidekiq, deve ser essa a razão pela qual configurar canais diferentes (servidores de e-mail distintos) para crítico para a missão e para resumo pode ser complicado. Vejo que não é tão simples quanto eu originalmente pensei (apenas configurar dois servidores de e-mail nos ambientes).

Aqui está a parte engraçada… LOL

No início, achei que seria uma boa ideia desativar os resumos por padrão pronto para uso em vez de deixá-los ativados com uma janela de login de 365 dias; mas então lembrei que o erro foi todo meu; e que não era uma boa sugestão para postar no meta, LOL.

Quando o Discourse foi instalado, ele definiu todos os usuários migrados (do nosso antigo fórum vB3), por padrão, como last_seen_at há cerca de 50 anos.

Fui ao banco de dados e alterei manualmente todos os usuários para “última visualização há 10 dias”! LOL. Na época, não tinha ideia sobre a configuração de resumos; e pensei que fosse um erro de migração ter todos os usuários com “última visualização há 50 anos” após a migração. Haha… eu estava errado. Há um bom motivo para isso.

O Discourse disparou um processo massivo de resumo semanal que sobrecarregou o sidekiq tanto no servidor de produção quanto no de staging; porque fiz a “hackeragem” de banco de dados “última visualização há 10 dias” no servidor de staging e exportei para a produção. Esse foi o erro que causou esse problema.

Como a maioria das pessoas não entra no postgres e faz gambiarras como eu, fazendo coisas como:

UPDATE users SET last_seen_at "hoje menos 10 dias"

… em uma migração legada com muitos usuários…

elas não terão esse tipo de problema massivo de resumo.

LOL

Peço desculpas por criar toda essa tensão por causa da minha gambiarra UPDATE na tabela users.

Ainda assim, acho razoável ter o e-mail crítico para a missão e o e-mail resumo em dois servidores de e-mail diferentes, mas olhando para o sidekiq, ainda não está claro para mim se há uma maneira simples de fazer isso, já que não tenho experiência (ainda) com o sidekiq.

No entanto, posso aconselhar os responsáveis por migrações: se você estiver migrando um fórum para o Discourse (o que é uma ótima ideia), deixe o last_seen_at padrão na tabela users como o padrão :slight_smile:

1 curtida
19

Geralmente, recomendo colocar o Mailhog entre uma instância de staging e o mundo exterior. Ele é excelente nesse tipo de cenário.

4 curtidas
20

Vou adicionar DISCOURSE_DISABLE _DIGEST _EMAILS às minhas instâncias de staging. Mas com os e-mails desativados para não funcionários, isso não é um grande problema.

2 curtidas