Reply by Email auto-hospedado parou de funcionar após a última atualização

Suporte
1

Meu fórum não responde mais a respostas enviadas por e-mail.

O recurso de responder por e-mail funcionava bem anteriormente, mas parece que essa funcionalidade parou de funcionar por volta de 29 de setembro.

Não tenho evidências definitivas sobre esse timing, pois o fórum não é muito ativo, mas certamente não funciona mais agora, e os logs do fórum não mostram mensagens recebidas após 29 de setembro.

O log de e-mails rejeitados também tem sua entrada mais recente em 29 de setembro. Todas as mensagens rejeitadas têm endereços descartáveis e conteúdo que parecem spam — então isso parece estar funcionando como deveria.

O log de e-mails com erro de entrega está vazio / mostra “nenhum log encontrado”.

As mensagens ainda estão sendo enviadas pelo fórum geradas por atividade de usuários logados (estou recebendo pelo menos), embora os níveis de atividade estejam ainda mais baixos que o normal devido ao problema acima. Quase todos os usuários ativos preferem e-mail em vez de interação baseada no navegador.

E-mails de teste com respostas para notificações de postagens do fórum enviadas tanto do meu próprio endereço de e-mail hospedado pela Microsoft quanto do meu Gmail não estão recebendo avisos de erro de entrega. Eles simplesmente desaparecem sem deixar rastros. Nada aparece no log de e-mails do fórum.

O log de erros do fórum mostra alguns avisos (ícone de exclamação amarelo) para 29 de setembro: “Email can not be processed: Email::Receiver::BadDestinationAddress Received…”, que parecem inofensivos / não diferentes de eventos semelhantes registrados anteriormente. Presumo que sejam apenas spam rejeitado.

Em 1º de outubro, há um erro real registrado como:

Mensagem

ActionDispatch::Http::MimeNegotiation::InvalidType (“%{#context[‘com.opensymphony.xwork2.dispatcher.httpservletresponse’].addheader(‘cbu0psig’” não é um tipo MIME válido)
lib/middleware/omniauth_bypass_middleware.rb:71:in call' lib/content_security_policy/middleware.rb:12:in call’
lib/middleware/anonymous_cache.rb:353:in call' config/initializers/100-quiet_logger.rb:23:in call’
config/initializers/100-silence_logger.rb:31:in call' lib/middleware/enforce_hostname.rb:23:in call’
lib/middleware/request_tracker.rb:187:in `call’

Rastreamento

actionpack (6.1.4.1) lib/action_dispatch/http/mime_negotiation.rb:31:in rescue in block in content_mime_type' actionpack (6.1.4.1) lib/action_dispatch/http/mime_negotiation.rb:24:in block in content_mime_type’
rack (2.2.3) lib/rack/request.rb:69:in fetch' rack (2.2.3) lib/rack/request.rb:69:in fetch_header’
actionpack (6.1.4.1) lib/action_dispatch/http/mime_negotiation.rb:23:in content_mime_type' actionpack (6.1.4.1) lib/action_dispatch/http/request.rb:269:in media_type’
actionpack (6.1.4.1) lib/action_dispatch/http/request.rb:355:in form_data?' rack (2.2.3) lib/rack/request.rb:445:in POST’
actionpack (6.1.4.1) lib/action_dispatch/http/request.rb:400:in block (2 levels) in POST' actionpack (6.1.4.1) lib/action_dispatch/http/parameters.rb:88:in parse_formatted_parameters’

Ambiente

HTTP HOSTS: nzarchitecture.net.nz

Não faço ideia se isso é relevante, e nenhum outro erro ou erro fatal (indicado por ícones de cruz vermelha clara ou escura) apareceu no log desde então.

Nenhum dos meus endereços de e-mail parece ser spam ou estar em listas negras quando testado em www.mail-tester.com, e não houve problemas de comunicação com pessoas reais a partir desses endereços.

O fórum usa o Mailgun, embora eu presuma que isso seja apenas para envio de e-mails em massa, e que quaisquer problemas com a conta do Mailgun ou a chave de API não deveriam afetar mensagens de entrada? Por acaso, não há problemas óbvios ou mensagens de erro com o Mailgun quando faço login na minha conta do Mailgun.

Presumo que a chave de API do Mailgun deve estar correta, já que o fórum ainda está enviando e-mails corretamente.

Nenhuma configuração do fórum foi alterada desde que responder por e-mail funcionava, e vejo que a caixa de seleção da configuração “responder por e-mail” ainda está marcada.

O fórum está hospedado na Digital Ocean. Nenhuma configuração DNS para o domínio foi alterada nas configurações da Digital Ocean, e os registros MX do fórum parecem estar ok/inalterados.

O fórum foi atualizado para a versão 2.8.0 beta 7 desde que o problema começou (presumivelmente com reconstrução no processo), mas sem melhoria.

O que estou deixando passar?
O que provavelmente deu errado?
Como faço para que responder por e-mail volte a funcionar?

1 curtida
2

Esse erro parece não ter relação.

De modo geral, é mais fácil testar o “email recebido” do que testar a resposta por email. Verifique as configurações de “polling manual ativado” e “email recebido”, adicione um endereço de email à categoria de equipe e veja se você consegue enviar um email para ele usando o mesmo endereço que usa para sua conta de administrador do fórum.

Em seguida, verifique em Admin - Email - Rejeitados / Recebidos / Rejeitados para ver o que está acontecendo.

Seu “endereço de resposta por email” está configurado corretamente?

5 curtidas
3

Olá, obrigado, Richard.

Posso confirmar que as configurações polling manual habilitado e entrada por e-mail ainda estão ativadas.

Adicionei meu endereço do Gmail como um endereço personalizado à categoria de equipe, mas não consigo ver uma maneira de enviar mensagens à equipe por meio do fórum? Todos os links “Fale conosco” estão configurados nas configurações do fórum como links mailto que vão diretamente para meu e-mail pessoal diário. Ao clicar em um deles, apenas abre meu aplicativo de e-mail, já preenchido com meu endereço de e-mail pessoal direto, o que significa que o fórum nunca receberá a mensagem.

4

Não, você deve configurar algo como staff@nzarchitecture.net.nz nas configurações da categoria e, em seguida, usar seu Gmail para enviar uma mensagem para esse endereço.

5

Ah, ok.

Tentei exatamente isso, mas nada apareceu em nenhum dos registros de Rejeitados / Recebidos / Devolvidos.

6

Seu servidor de e-mail está configurado para a Digital Ocean.

image
image745×151 10.5 KB

Você tem um servidor de e-mail com eles?

7

Este é o IP do droplet, que está executando o mail-receiver.

nzarchitecture.net.nz. 2727 IN A 159.65.140.176

8

Isso mudou nos últimos 5 meses

image
image1123×176 3.28 KB

9

Sei o que está acontecendo. É aquela coisa @#(($* do LetsEncrypt que quebrou metade da internet muitas coisas em 30 de setembro.

Basta reconstruir o Docker do receptor de e-mail.

6 curtidas
10

hahahahaha, sim. Eu esqueci disso. Kkkkk

3 curtidas
12

Você precisa seguir o tópico que @RGJ postou.

Isso deve resolver seu problema.

4 curtidas
13

Ah, ok. Isso parece promissor!
Como faço para reconstruir o “receptor de e-mail do Docker”? Isso é diferente da reconstrução do “gerenciador do Docker” que ocorre ao atualizar o fórum pelo painel de controle?

Devo apenas seguir isto? Como atualizar manualmente o Discourse e a imagem do Docker para a versão mais recente? - como fazer / administradores - Discourse Meta

14

Você precisa fazer login no lado de linha de comando do seu site.

Não é através do painel de administração do fórum.

15

Olá, consegui reconstruir o receptor de e-mail do Docker usando as instruções daquele link Entrega direta de e-mails recebidos para sites auto-hospedados - howto / sysadmin - Discourse Meta.

Fui obrigado a fazer upgrade/redimensionar meu droplet no Digital Ocean para fazer isso, pois mesmo após excluir todos os backups etc. armazenados no host, não havia espaço em disco suficiente para uma reconstrução.

Após a reconstrução, consegui enviar aquela mensagem para staff@nzarchitecture.net.nz e o fórum, desta vez, reconheceu o recebimento.
No entanto, quando tento responder por e-mail a um tópico existente do fórum sobre o qual fui notificado, embora as mensagens recebidas sejam agora reconhecidas, nenhuma aparece no fórum e todas geram avisos de Falha na Entrega de E-mail no log de e-mail.

As mensagens recebidas não aparecem no log de E-mails Rejeitados, mas todas aparecem no log de E-mails Rejeitados com o aviso [Email::Receiver::BadDestinationAddress] — incluindo minha própria conta de e-mail de administrador, que eu esperava não ter de repente um endereço de destino inválido.

16

Você reconfigurou seu receptor de e-mail recentemente?

3 curtidas
17

Sim - fiz isso há cerca de meia hora, o que resultou na postagem acima.
Acabei de fazer outra reconstrução completa e (fingers crossed) as coisas parecem estar funcionando novamente.

1 curtida
18

Pode ser que o “force https” não estivesse configurado e a reconstrução tenha corrigido isso.

1 curtida
19

Na verdade, eu havia acabado de ver um aviso exatamente sobre isso no painel e, por isso, cliquei no link conveniente fornecido para a configuração apropriada e marquei a caixa.

Não percebi que o HTTPS forçado era obrigatório para receber e-mails de entrada.

É possível que a falta de HTTPS forçado também tenha causado problemas ao usar o login do Facebook. Recentemente, fui notificado pelo Facebook de que meu site estava em violação dos termos de serviço deles e foi suspenso. Não havia itens de ação no painel de desenvolvedor de aplicativos do Facebook, então fiz um recurso, e a resposta foi de que eles não conseguiram verificar o site devido a um erro não especificado gerado pela URL do meu fórum.

1 curtida
20

Parece que marcar a caixa “forçar HTTPS” não ajudou em nada com o login do Facebook. O suporte técnico do Facebook ainda afirma que a página de aterrissagem do site gera um aviso de segurança “sua conexão não é privada NET::ERR_CERT_COMMON_NAME_INVALID” para eles.

O emissor do certificado, conforme mostrado na página de erro, é “R3” — o que uma pesquisa no Google sugere estar relacionado ao Let’s Encrypt — as mesmas pessoas cujo vencimento de certificado desencadeou a necessidade de reconstruir a instalação do Discourse.

Isso é uma coincidência? Isso sugere que a última versão do Discourse (2.8.0 beta 7) ainda tem um problema com certificado? Ou isso é um problema não relacionado, ligado à hospedagem/Digital Ocean?

21

Minha própria pesquisa desajeitada no Google me levou a testar minha URL usando https://www.whynopadlock.com/, e os resultados me encaminharam para esta publicação de um usuário do Let’s Encrypt:

O Let’s Encrypt atualizou recentemente seu certificado intermediário de “Let’s Encrypt Authority X3” para “R3”.

Se você utiliza um cliente ACME bem comportado, ele deve ter começado automaticamente a usar o novo certificado intermediário na sua última renovação. Você não deveria ter notado nenhuma diferença.

No seu caso, talvez você esteja codificando manualmente o certificado intermediário. Se for esse o caso, será necessário usar o novo certificado intermediário, que você pode encontrar em https://letsencrypt.org/certificates: https://letsencrypt.org/certs/lets-encrypt-r3-cross-signed.pem

Será que a versão atual do Discourse está, porventura, codificando erroneamente o certificado intermediário?

Os “certificados intermediários” são algo que os administradores do Discourse agora precisam gerenciar? E, se sim, como?

Por favor, me avise se estou fora do tópico — não tenho certeza se isso faz parte do mesmo problema ou não.