Atualização do mail-receiver auto-hospedado após alteração no certificado raiz Let's Encrypt

Suporte Instalação
,
1

Este anúncio afeta apenas usuários que fazem auto-hospedagem e estão executando Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver. Clientes de hospedagem gerenciada e auto-hospedeiros que usam POP3 para recebimento de e-mail não são afetados.

Como você deve saber, a Let’s Encrypt recentemente alterou seu certificado raiz. O antigo certificado raiz expirou hoje e causou vários problemas em clientes desatualizados em toda a web. Todos os nossos sistemas na CDCK estão atualizados e não foram afetados pela expiração de hoje. Infelizmente, esquecemos da imagem Docker pública do receptor de e-mail, que não era atualizada há alguns meses.

Isso significa que instalações existentes de receptor de e-mail em auto-hospedagem não conseguirão entregar e-mails para sites protegidos pela Let’s Encrypt.

Acabamos de enviar uma versão atualizada para o DockerHub, que inclui o novo certificado raiz. Se você seguiu as instruções oficiais de instalação, pode atualizar sua instalação executando:

docker pull discourse/mail-receiver:release
cd /var/discourse
./launcher rebuild mail-receiver

E-mails recebidos por instalações com problemas foram temporariamente enfileirados no servidor de envio. Esses servidores devem tentar reentregar os e-mails periodicamente, portanto, qualquer e-mail perdido deve chegar logo após você atualizar a imagem.

Se você ainda estiver enfrentando problemas após seguir estas etapas, verifique se está executando a versão release do mail-receiver. Você pode encontrar informações sobre isso neste tópico.

Pedimos desculpas pelo transtorno! Um grande agradecimento ao @wlandgraf por ter relatado inicialmente o problema e ajudado a testar a correção :heart:

28 curtidas
2

Obrigado pela correção! Minha atualização travou com a seguinte mensagem de erro. Não fiz nenhuma alteração neste modelo, então não tenho certeza do que fazer?

root@ba /var/discourse # ./launcher rebuild mail-receiver
Garantindo que o launcher esteja atualizado
Buscando origem
Atualizando o Launcher...
Atualizando 46d899f..990519e
erro: Suas alterações locais nos seguintes arquivos seriam sobrescritas pela mesclagem:
	templates/web.letsencrypt.ssl.template.yml
Por favor, faça commit das suas alterações ou guarde-as antes de mesclar.
Abortando
falha ao atualizar
1 curtida
3

O que acontece se você executar

cd /var/discourse
git diff

Ele mostra alguma diferença no arquivo web.letsencrypt.ssl.template.yml?

Se sim, você pode redefiní-las usando git reset --hard.

3 curtidas
4

Ah, eu realmente fiz uma mudança :innocent: Consegui atualizá-lo agora, obrigado!

2 curtidas
5

Você pode testar se está executando o antigo mail-receiver da seguinte forma.

docker exec mail-receiver bash -c "cat /etc/issue|grep Alpine"

Se for Alpine, é o antigo.

docker exec mail-receiver bash -c "cat /etc/issue|grep 'Debian GNU/Linux 11'"

Se for Debian, é o novo.

7 curtidas
6

@david, você se importaria de dar uma olhada nos problemas abaixo? A última atualização do mail-receiver removeu a capacidade de implementar medidas adicionais anti-spam, que funcionavam maravilhosamente na versão anterior, e meu fórum está sob pressão crescente de spam novamente devido à última alteração.

Tentei descobrir qual é o problema raiz, mas não tenho conhecimento profundo o suficiente do Postfix para resolvê-lo. Encontrei relatos semelhantes (client=unknown mesmo quando o registro PTR existe no DNS) relacionados ao Postfix em uma gaiola chroot, então isso pode ter algo a ver com isso. Além disso, os dnsutils parecem estar ausentes na nova imagem Debian do mail-receiver, mas instalá-los ainda não resolve o problema?

Este aqui deve ser corrigido facilmente:

4 curtidas
7

@david Obrigado por esta correção! Acabei de executá-la e consigo ver que está funcionando. :+1:

Existe alguma maneira de ver quais e-mails não puderam ser entregues desde 1º de outubro?

Tentei isto, mas só vejo 5 solicitações (a mais antiga foi recebida em 26 de novembro):

/var/discourse/launcher enter mail-receiver
mailq

Também tentei olhar os logs, mas só obtive o aviso relatado aqui:

3 curtidas
8

Acho que qualquer coisa que ainda não esteja na fila deveria ter sido devolvida ao remetente. Receio não ter certeza se o contêiner possui logs que remontem a um período anterior ao que você encontrou.

4 curtidas
9

Simplesmente adicionar pull_image após a linha 657 resolveria a necessidade de puxar explicitamente a imagem antes da reconstrução? Ou seja:

  # Se a imagem que está sendo inicializada não for a imagem base do Discourse
  if [[ ! X"" = X"$base_image" ]]; then
    image=$base_image
    # Tenta atualizar a imagem
    pull_image
  fi

Isso fará com que um docker pull $image sempre aconteça durante a inicialização/reconstrução de um contêiner com base_image definido em seu arquivo yml. Não acho que isso prejudique o mail-receiver se ele já estiver atualizado, mas não tenho certeza se há outras situações em que isso poderia ser um problema.

2 curtidas
10

Sim, um pull incondicional provavelmente faz sentido aqui. É um pouco estranho que ele se aplique apenas à nossa imagem base principal no momento. O que você acha, @Falco?

2 curtidas
11

Eu estaria interessado em ouvir uma resposta definitiva para esta pergunta :slight_smile:

1 curtida
12

Eu acho que você pode ver isso consultando a tabela incoming_emails do postgres

2 curtidas
13

Infelizmente, isso não mostra nada no período relevante (outubro de 2021 a fevereiro de 2022).

Haveria algum log no próprio container do receptor de e-mail?

1 curtida