Serviço de Email Transacional (Código Aberto)

Olá, vi que todos sugerem serviços de e-mail dedicados. Alguém usa ou já experimentou alternativas de código aberto? Por exemplo, postal ou cuttlefish.

Certamente, usar seu próprio servidor, pelo menos para lidar com e-mails de saída, traria enormes benefícios. Serviços como SendGrid ou Mailgun custam muito, se você tem uma comunidade que envia 1 milhão de notificações ou até mais por mês. Eu olhei as configurações, um usuário pode receber 250/300 notificações por e-mail por dia muito facilmente… se você tem uma comunidade ativa, de acordo com meus cálculos, você excede pelo menos um milhão ou chega muito perto.

E, de qualquer forma, como você gerencia usuários que configuram e-mails para cada postagem ou resumos a cada 30 minutos, mas que depois talvez nunca mais façam login. Talvez possa haver usuários que façam isso por maldade. Você altera as configurações para aqueles usuários que não estão ativos por mais de alguns meses?

Obrigado antecipadamente!

1 curtida

Este é um problema real que você está tendo ou um que você imagina? Lidar com spammers humanos é um problema para algumas comunidades, mas não para muitas.

Sim, se você está enviando um milhão de e-mails por mês, talvez tenha uma equipe capaz de gerenciar um servidor web. Mas fazer isso não é algo suportado aqui, é por isso que essas ferramentas têm suas próprias comunidades. Para a maioria das pessoas, gerenciar um servidor de e-mail é um fardo enorme, e é por isso que esses serviços são recomendados.

Eu honestamente não entendo por que isso deveria ser difícil. Existem esses projetos de código aberto, criados com o propósito de gerenciar tudo de forma simples. É difícil gerenciar até mesmo um fórum, mas o Discourse é um CMS criado para tornar tudo o mais simples possível. Uma vez instalado o Postal e configurado bem o DNS (o mesmo com serviços externos ou você terá problemas da mesma forma), que problemas poderiam existir?

A única coisa que deveria ser feita é testar se tudo funciona com o Discourse (por exemplo, usando-o para recebimento também e habilitando resposta por e-mail etc.), se ele é compatível. Por isso perguntei se alguém está usando algum desses projetos de código aberto.

Posso estar errado, mas acho que continuar dizendo “é muito difícil gerenciar um servidor de e-mail e, portanto, você tem que usar serviços pagos” é apenas uma desculpa. Se alguém sabe como instalar o Discourse, com um pouco de esforço, também instala outros CMS, por exemplo, o Postal.

Porque spam. Mas tente. Existem vários pacotes que tornam a mecânica de configurar as coisas bem fácil.

1 curtida

Eu uso mail-in-a-box e mail-receiver, funciona (com alguns ajustes no postfix). Não é que seja difícil, mas está fora do escopo do suporte do meta. Além disso, acho que manter a reputação do IP e do domínio é um incômodo. Quando não é algum ISP aleatório que de repente decide que você é 550 5.7.1 para os usuários deles, é o Google e…:face_with_symbols_over_mouth:. parece que nunca acaba.

5 curtidas

Meu receio é apenas para quando os usuários talvez assistam às categorias e, em seguida, recebam e-mails para cada novo tópico e postagem. E se eles estiverem inativos? Continuo enviando 100 e-mails por dia para cada um deles, todos os meses? Como 3.000 e-mails também enviados para membros que não estão mais ativos, mas que haviam ativado essa configuração anteriormente, talvez.

Existe alguma maneira de desativar a capacidade de assistir a categorias? Dar apenas a possibilidade de assistir por tópico? Isso resolveria tudo, eu acho.

o parâmetro max emails per day per user também pode ser útil (o padrão é 100)

2 curtidas

Eu não usei, mas a opção suppress digest email after days (suprimir e-mail de resumo após dias) seria útil também?

3 curtidas

Eu vim aqui por causa do postal. Acho as perguntas relevantes e gostaria de propor o seguinte.

Suponho que haja uma maneira, usando o Discourse Data Explorer, de encontrar quem recebeu e-mail, mas não fez login nos últimos 6 meses, e então enviar um e-mail perguntando se eles ainda estão interessados ou se apenas ignoram o e-mail. Se, após, digamos, mais uma semana, não houver resposta, pare de enviar e-mails e, eventualmente, exija a validação da conta (ou seja, suspenda a conta por inatividade).

Isso certamente economizaria muitos ciclos de CPU e largura de banda de rede (e energia e água…) ao não enviar e-mails inúteis pela Internet em todas as milhares de instâncias do Discourse. :green_heart:

Funciona praticamente dessa forma. Configuração do site “suprimir e-mail de resumo após dias”.

3 curtidas

Essa configuração impede todos os e-mails, por exemplo, notificações de novas postagens em categorias observadas?

Não. Não faz. Muitas pessoas usam o Discourse apenas por e-mail (o que acho estranho, mas nem todo mundo é como eu).

Portanto, se você quiser que todos os e-mails parem para pessoas que não fizeram login por um período, você precisaria de um plugin para fazer algo como você sugere. Talvez você envie a elas um link de login com um cabeçalho especial como aviso e, em seguida, desative a conta.

Não acho que faria uma diferença mensurável em termos de energia. A menos que um monte de usuários esteja observando uma categoria movimentada, provavelmente não fará muita diferença, mesmo nos custos de e-mail. Se esse é o seu objetivo, provavelmente não vale a pena.

1 curtida

Talvez você possa tentar rotear e-mails via Amazon SES?

E-mails (pelo menos este aspecto dos e-mails) parecem se resolver sozinhos — é fácil cancelar a inscrição e, quando as pessoas mudam de empresa, seus e-mails começam a retornar.

1 curtida