Configurar email de entrada para entrega direta em sites hospedados por você com Mail-Receiver

Documentação Auto-hospedagem
, , ,
532

Como exatamente desativar o suporte DMARC?

Ou seja, adicionar INCLUDE_DMARC: false à seção env de mail-receiver.yml não parece resolver. Isso parece fazer com que os daemons opendkim e opendmarc não sejam executados (levando a um aviso nos logs), mas a verificação SPF ainda está sendo realizada.

Editado para adicionar:
Acho que consegui desativar as verificações SPF adicionando também a seguinte linha POSTCONF_ à seção env:

env:
  ...
  INCLUDE_DMARC: false
  POSTCONF_smtpd_recipient_restrictions: check_policy_service unix:private/policy
  ...

Consegui isso olhando o commit que introduziu as verificações DMARC, e vendo o que deveria acontecer quando INCLUDE_DMARC é falso.

Sei quase nada sobre como as imagens docker são construídas, mas tenho a impressão de que o sinalizador INCLUDE_DMARC é algo que deve ser definido por outra pessoa, em outro lugar, em outro momento — não algo que possa ser feito em mail-receiver.yml.

2 curtidas
533

Encontrei a necessidade de abrir a porta 443 no ufw — caso contrário, recebo API Request Preparation Failed nos logs. Pensei que isso deveria ser mencionado porque as instruções de instalação padrão mencionam a ativação do ufw.

A porta 25 é mencionada em mail-receiver.yml e parece contornar o ufw.

1 curtida
534

O repositório do GitHub deve estar no OP?

3 curtidas
535

Usuários do mail-receiver, por favor, vejam Remove smtp_should_reject & discourse-smtp-fast-rejection

Vamos remover completamente a rejeição rápida, pois o recurso original estava quebrado e causando problemas aos usuários, especificamente este tipo de coisa:

e também afeta e-mails encaminhados, pois o teste pré-entrega estava verificando o envelope-from e o envelope-to, enquanto o Discourse usa apenas os valores nos cabeçalhos.

1 curtida
536

Acabei de enviar este PR para remover as aspas desnecessárias em torno do valor de DISCOURSE_BASE_URL no arquivo de exemplo mail-receiver.yml. As aspas estavam quebrando minha configuração. Livrar-se das aspas permite a conclusão bem-sucedida deste documento.

537

Você pode explicar como? A presença/ausência de aspas ao redor deste valor não produz diferença:

[2] pry(main)=> YAML::load("env:\n  DISCOURSE_BASE_URL: 'https://discourse.example.com'")
=> {"env"=>{"DISCOURSE_BASE_URL"=>"https://discourse.example.com"}}

[3] pry(main)=> YAML::load("env:\n  DISCOURSE_BASE_URL: https://discourse.example.com")
=> {"env"=>{"DISCOURSE_BASE_URL"=>"https://discourse.example.com"}}
538

Ao acompanhar os logs daquele contêiner e enviar mensagens para ele, eu estava vendo um monte de erros mencionando algo como discourse.example.com não faz parte dos registros MX ou algo assim. Eu removi as aspas, reconstruí o contêiner e começou a funcionar :person_shrugging:

A sequência de eventos também pode importar:

  1. Configurei e iniciei o contêiner mail-receiver
  2. Alguns dias depois, configurei os registros DNS MX
  3. Validei que os registros MX estavam configurados corretamente e então comecei a testar. Não estava funcionando
  4. Removi as aspas, reconstruí o contêiner, começou a funcionar

Então não tenho certeza se a resolução estava relacionada à remoção das aspas, ou à reconstrução do contêiner depois que os registros MX foram criados.

No pior dos casos, o PR deixa o yml com aparência consistente :slight_smile:

1 curtida