Actualización del receptor de correo autohospedado tras el cambio en el certificado raíz de Let's Encrypt

Instalación
,
1

This announcement only affects self-hosters who are running Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver. Managed hosting customers, and self-hosters using POP3 for incoming mail are not affected.

As you may be aware, Let’s Encrypt recently changed their root certificate. The old root certificate expired today, and has caused a number of issues for out-of-date clients across the web. All of our systems at CDCK are up-to-date, and were not affected by today’s expiration. Unfortunately we missed the public mail-receiver docker image, which has not been updated for a few months.

This means that existing self-hosted mail-receiver installations will be unable to deliver mail to letsencrypt-secured sites.

We just pushed an updated version to DockerHub, which includes the new root certificate. Assuming you followed the official installation instructions, you can update your installation by running

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

Mails received by broken installations will have been temporarily queued on the sending server. Those servers should attempt to redeliver the mail periodically, so any missed mails should arrive soon after you update the image.

If you’re still seeing issues after following these steps, make sure you’re running the release version of mail-receiver. You can find information on that in this topic.

Sorry for the disruption here! Big thanks to @wlandgraf for initially reporting the issue, and helping us test the fix :heart:

28 Me gusta
2

Thanks for the fix! My update got stuck with the following error message. I haven’t made any changes to this template, so I’m not sure what to do?

root@ba /var/discourse # ./launcher rebuild mail-receiver
Ensuring launcher is up to date
Fetching origin
Updating Launcher...
Updating 46d899f..990519e
error: Your local changes to the following files would be overwritten by merge:
	templates/web.letsencrypt.ssl.template.yml
Please commit your changes or stash them before you merge.
Aborting
failed to update
1 me gusta
3

What happens if you

cd /var/discourse
git diff

Does it show any differences in the web.letsencrypt.ssl.template.yml file?

If so, you can reset them using git reset --hard

3 Me gusta
4

Ah, I did make a change :innocent: I got it to upgrade now, thanks!

2 Me gusta
5

You can test whether you’re running the old mail-receiver like this.

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

If it’s Alpine, it’s the old one.

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

If it’s Debian, it’s the new one.

7 Me gusta
6

@david, would you mind having a look at the issues below, the latest update to the mail-receiver removed the ability to implement additional anti-spam measures, which worked wonders in the previous version, and my forum is under increasing spam pressure again due to the last change.

I tried to figure out what the root issue is, but I don’t have deep enough knowledge of postfix to figure it out. I found similar reports (client=unknown even when PTR record exists in DNS) regarding postfix in a chroot jail, so this might have something to do with it. Also, dnsutils seem to be missing from the new mail-receiver Debian image, but installing them still doesn’t fix the issue?

This one should be fixed easily:

4 Me gusta
7

@david ¡Gracias por esta corrección! Acabo de ejecutarla y veo que está funcionando. :+1:

¿Hay alguna forma de ver qué correos electrónicos no pudieron ser entregados desde el 1 de octubre?

He intentado esto, pero solo veo 5 solicitudes (la más antigua se recibió el 26 de noviembre):

/var/discourse/launcher enter mail-receiver
mailq

También intenté mirar los registros, pero solo obtuve la advertencia informada aquí:

3 Me gusta
8

Creo que cualquier cosa que todavía no esté en la cola debería haber sido devuelta al remitente. Me temo que no estoy seguro de si el contenedor tiene algún registro que vaya más allá de lo que has encontrado.

4 Me gusta
9

¿Simplemente agregar pull_image después de la línea 657 resolvería la necesidad de extraer explícitamente la imagen antes de reconstruirla? Es decir:

  # Si la imagen que se está iniciando no es la imagen base de Discourse
  if [[ ! X"" = X"$base_image" ]]; then
    image=$base_image
    # Intenta actualizar la imagen
    pull_image
  fi

Esto provocará que siempre ocurra un docker pull $image durante el inicio/reconstrucción de un contenedor con base_image establecido en su archivo yml. No creo que eso perjudique a mail-receiver si resulta que ya está actualizado, pero no estoy seguro si hay otras situaciones en las que eso podría ser un problema.

2 Me gusta
10

Sí, un pull incondicional probablemente tenga sentido aquí. Es un poco extraño que solo se aplique a nuestra imagen base principal en este momento. ¿Qué opinas @Falco?

2 Me gusta
11

Me interesaría escuchar una respuesta definitiva a esta pregunta :slight_smile:

1 me gusta
12

Creo que puedes verlo consultando la tabla incoming_emails de postgres.

2 Me gusta
13

Lamentablemente, eso no muestra nada en el período de tiempo relevante (octubre de 2021 a febrero de 2022).

¿Habría algún registro en el propio contenedor del receptor de correo?

1 me gusta