Usar servidor de e-mail local/sendmail para e-mails de saída?

Instalação Hospedagem
1

Configuramos nosso próprio servidor de e-mail e eu estava pensando em como usá-lo melhor com o contêiner Docker do Discourse.

Claro, posso simplesmente configurar nossos detalhes e credenciais de SMTP, mas parece uma sobrecarga desnecessária, já que o servidor SMTP roda na mesma máquina.

sendmail funciona, mas o Discourse está no contêiner, portanto, não tem acesso ao sendmail em seu host.

Pesquisar algo aqui no fórum dá um exemplo onde DISCOURSE_SMTP_DOMAIN foi usado sem credenciais, onde fazer o mesmo com swaks dentro do contêiner funciona: How to get Discourse to work with Postfix - #18 by sonmicrosystems que, nesse caso, ainda seja o envio normal de SMTP na porta padrão, e o Postfix o aceita sem autenticação, já que a solicitação vem de localhost?

Alguém está ciente de outro método? Vejo que a biblioteca Ruby usada geralmente suporta tudo: https://github.com/discourse/mail\nNas configurações do Discourse, o que me chamou a atenção foi um campo Delivery method:

image
image643×198 6.22 KB

Não consigo alterar essas configurações na GUI, suponho que porque o YAML do contêiner as impõe via DISCOURSE_SMTP_ADDRESS etc.? Mas não consigo encontrar uma variável para o método de entrega.

Talvez alguém conheça outra maneira, e até lá, estou configurando a autenticação normal da porta de envio de SMTP. Obrigado por DISCOURSE_SMTP_FORCE_TLS, adicionado mais recentemente, mas ainda não faz parte de nenhuma amostra (deveria fazer). Não pretendo permitir STARTTLS, mas apenas TLS implícito/imediato.

2

Sobrecarga desnecessária como? Você tem que enviar os dados do Discourse para o servidor SMTP de alguma forma? Não?

Ps: se for outro contêiner, você poderia, em teoria, usar a rede bridge e usar o nome do contêiner smtp em vez do nome do host, se é isso que você procura, mas isso não lhe dará nenhuma vantagem de desempenho.

2 curtidas
3

Existem duas maneiras de enviar e-mails através de um servidor SMTP local:

  1. conectar-se e autenticar-se na porta de submissão, como 587 com STARTTLS ou 465 com TLS implícito/imediato => solicitação de rede, verificações e restrições aplicadas via smtpd
  2. usar sendmail ou similar, que invoca o comando local pickup (no caso do Postfix), sem fazer nenhuma conexão de rede e contornando todas as verificações e restrições configuradas para o serviço de submissão smtpd.

O último é mais simples e rápido, implementado em sistemas e frameworks de tempo de execução comuns, como PHP mailer e esta biblioteca de e-mail Ruby usada pelo Discourse. E a autenticação é contornada, nenhuma credencial em texto simples precisa ser armazenada em qualquer lugar. Ou, em outras palavras: o servidor SMTP não é usado em nenhum caso, mas apenas o cliente SMTP.

Quero dizer, sim, a conexão com a porta de submissão não deve ter impacto significativo na carga do servidor, em comparação com o que o Discourse faz de outra forma. O último ponto pode ser resolvido com, por exemplo, a regra smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject na porta de submissão, para permitir submissões de IPs de loopback (padrão, configuração mynetworks) antes de fazer qualquer autenticação. Se a solicitação do contêiner for vista com outro IP, ela pode ser adicionada a mynetworks. Acho que foi assim que funcionou no caso do tópico que linkei antes.

Veremos na próxima vez que atualizarmos/reconstruirmos nosso Discourse, quando as configurações SMTP alteradas forem aplicadas. Relatarei como funciona.

Mas ainda seria interessante saber se existem outras maneiras e o que essa configuração “Método de entrega” significa.

O Postfix é executado no host, não dentro de um contêiner, mas não faria muita diferença, pois permanece uma autenticação baseada em rede.

Sim, um pensamento posterior, faz sentido que sendmail etc. do host/outro contêiner não possam funcionar dentro de um contêiner, pois requerem acesso direto a vastas partes dos executáveis, bibliotecas e configurações do Postfix, suponho. A menos que haja uma espécie de socket mágico que possa ser montado no contêiner ou algo assim :smile:.

2 curtidas
4

Faz tempo que não me aprofundo tanto no microgerenciamento do sendmail. Tenho o Mailcow stack em uma VM e o Discourse em outra. Não sei se um dia valerá a pena se aprofundar tanto, a não ser por diversão.

Desejo tudo de bom em suas aventuras, volte para contar o que aprendeu.

1 curtida
5

Provavelmente não :sweat_smile:. Mas sou perfeccionista em certos contextos e gosto de me aprofundar e aprender todos os detalhes. Levei várias noites para configurar Dovecot, Postfix, rspamd, dkimpy-milter, PostSRSd, … passo a passo, aprendendo sobre quase todas as configurações disponíveis, por que os padrões são assim, se e por que podemos querer de forma diferente, etc. Mas ei, agora parece que entendo a maioria das coisas melhor do que a maioria dos autores de guias arbitrários de servidores de e-mail por aí :face_with_tongue:.

6

Estou movendo este tópico para Installation > Hosting. Não recomendamos tentar hospedar seu próprio servidor de e-mail, como você sabe se leu as instruções oficiais de instalação. E-mail é difícil!

7

Não tenho certeza do que o Discourse tem a ver com o fato de o sistema poder ou não hospedar um servidor de e-mail adicional? Além do fato de que isso teoricamente abre outra maneira de enviar e-mails, é claro.

Para receber e-mails (outro tópico), no entanto, tem um efeito, já que não se pode hospedar o contêiner receptor de e-mail, pelo menos não para escutar diretamente na porta 25. Mas usar a API do receptor de e-mail do Discourse diretamente se revelou apenas 2-3 linhas na configuração do Postfix: Is there a way to only IMAP polling for incoming emails - #2 by MichaIng

Mas concordo, configurar o servidor de e-mail corretamente não foi exatamente uma tarefa fácil, como mencionado acima. Mas super interessante de aprender :slightly_smiling_face:.

1 curtida
8

Sim! É desafiador e interessante, com certeza. Passei pelas minhas próprias aventuras instalando todos os tipos de serviços e tentando executá-los eu mesmo, em uma vida passada! :upside_down_face:

Fico feliz em ter você atualizando este tópico com seus aprendizados para o benefício de futuros viajantes intrépidos, incluindo você. Mas tenha em mente que a categoria Support é para instalações suportadas, o núcleo do Discourse e plugins e componentes oficiais.

1 curtida
9

o quê. Dovecoat bom. Por que então postfix? Por que não dovecoat exim?

10

O que há de errado com o Postfix? Ele fazia parte do primeiro guia de configuração de servidor de e-mail que li, e suas opções de filtro interno para reduzir spam e acesso de bots no início do pipeline pareciam um bom argumento.

Bem, meio que fora do tópico, em relação ao uso de sendmail/pickup do Discourse.

Marcando isso como resolvido/respondido. Faz sentido que o contêiner do Discourse não possa acessar o sendmail do host, não importa qual servidor. Portanto, ele precisa usar a submissão SMTP, para a qual se pode autenticar, por exemplo, via intervalo de IP do contêiner Docker no Postfix, pulando a autenticação passdb/userdb no Dovecot.

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.