Reply by Email auto-hébergé a cessé de fonctionner après la dernière mise à jour

[Paul_King]

Mon forum ne répond plus aux réponses envoyées par e-mail.

La fonctionnalité de réponse par e-mail fonctionnait auparavant correctement, mais il semble qu’elle ait cessé de fonctionner vers le 29 septembre.

Je n’ai aucune preuve définitive de ce timing, car le forum n’est pas très actif, mais il est certain que cela ne fonctionne plus désormais, et les journaux du forum n’indiquent aucun message reçu après le 29 septembre.

Le journal des e-mails rejetés contient également son entrée la plus récente datant du 29 septembre. Tous les messages rejetés proviennent d’adresses jetables et contiennent du contenu qui ressemble à du spam – ce qui semble indiquer que cette partie fonctionne comme prévu.

Le journal des e-mails en rebond est vide ou affiche « aucun journal trouvé ».

Les messages continuent d’être envoyés par le forum suite à l’activité des utilisateurs connectés (je les reçois du moins), bien que le niveau d’activité soit encore plus faible que d’habitude en raison de ce qui précède. Presque tous les utilisateurs actifs préfèrent l’e-mail plutôt que l’interaction via le navigateur.

Les réponses testées par e-mail aux notifications de publication du forum, envoyées depuis mon adresse e-mail hébergée par Microsoft ou depuis mon adresse Gmail, ne génèrent aucun avertissement de rebond. Elles disparaissent simplement sans laisser de trace. Rien n’apparaît dans le journal des e-mails du forum.

Le journal des erreurs du forum affiche quelques avertissements (icône d’exclamation jaune) pour le 29 septembre : « Email can not be processed: Email::Receiver::BadDestinationAddress Received… », qui semblent anodins et ne diffèrent pas des événements similaires précédemment enregistrés. Je suppose qu’il s’agit simplement de spam rejeté.

Le 1er octobre, une véritable erreur a été enregistrée :

Message

ActionDispatch::Http::MimeNegotiation::InvalidType (“%{#context[‘com.opensymphony.xwork2.dispatcher.httpservletresponse’].addheader(‘cbu0psig’” n’est pas un type MIME valide)
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’

Backtrace

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’

Env

HTTP HOSTS: nzarchitecture.net.nz

Je ne sais pas si cela est pertinent, et aucune autre erreur ou erreur fatale (indiquée par une croix rouge claire ou foncée) n’est apparue dans le journal depuis lors.

Aucune de mes adresses e-mail ne semble suspecte ou répertoriée sur www.mail-tester.com, et aucun problème de communication avec des humains depuis ces adresses n’a été constaté.

Le forum utilise Mailgun, bien que je suppose que cela ne serve qu’à l’envoi d’e-mails en masse, et que tout problème lié au compte Mailgun ou à la clé API ne devrait pas affecter les messages entrants ? En fait, aucun problème ou message d’erreur évident n’apparaît dans mon compte Mailgun lorsque je me connecte.

Je suppose que la clé API Mailgun doit être valide puisque le forum continue d’envoyer correctement les e-mails.

Aucun paramètre du forum n’a été modifié depuis que la réponse par e-mail fonctionnait, et je constate que la case à cocher « réponse par e-mail » est toujours activée.

Le forum est hébergé sur Digital Ocean. Aucun paramètre DNS pour le domaine n’a été modifié dans les paramètres de Digital Ocean, et les enregistrements MX du forum semblent corrects et inchangés.

Le forum a été mis à jour vers la version 2.8.0 bêta 7 depuis le début du problème (avec une reconstruction présumée durant le processus), mais aucune amélioration n’a été constatée.

Qu’est-ce que je rate ici ?
Qu’est-ce qui a probablement mal tourné ?
Comment puis-je faire en sorte que la réponse par e-mail fonctionne à nouveau ?

[RGJ (Richard - Communiteq)]

Cette erreur semble sans rapport.

En général, il est plus simple de tester l’« envoi par e-mail » que la réponse par e-mail. Activez les paramètres « polling manuel activé » et « envoi par e-mail », ajoutez une adresse e-mail à la catégorie du personnel, puis vérifiez si vous pouvez envoyer un e-mail à cette adresse en utilisant la même adresse que celle de votre compte administrateur du forum.

Ensuite, vérifiez dans Admin - E-mail - Rejetés / Reçus / Rejetés pour voir ce qui se passe.

Votre « adresse de réponse par e-mail » est-elle configurée correctement ?

[Paul_King]

Bonjour, merci Richard,

Je peux confirmer que les paramètres « polling manuel activé » et « email entrant » sont toujours activés.

J’ai ajouté mon adresse Gmail en tant qu’adresse personnalisée dans la catégorie « personnel », mais je ne vois pas de moyen d’envoyer des messages au personnel via le forum ? Tous les liens « contactez-nous » sont configurés dans le texte des paramètres du forum sous forme de liens mailto qui redirigent simplement vers mon adresse e-mail personnelle quotidienne. Cliquer sur l’un d’eux ouvre simplement mon application de messagerie, préremplie avec mon adresse e-mail personnelle directe, ce qui signifie que le forum ne recevra jamais le message.

[RGJ (Richard - Communiteq)]

@Paul_King

J’ai ajouté mon adresse Gmail en tant qu’adresse personnalisée dans la catégorie du personnel.

Non, vous devez configurer quelque chose comme staff@nzarchitecture.net.nz dans les paramètres de la catégorie, puis utiliser votre Gmail pour envoyer un message à cette adresse.

[Paul_King]

Ah, d’accord.

@RGJ

Configurez quelque chose comme staff@nzarchitecture.net.nz dans les paramètres de la catégorie, puis utilisez votre Gmail pour envoyer un message à cette adresse.

J’ai essayé exactement cela, mais rien n’est apparu dans aucun des journaux de rebonds / reçus / rejetés.

[IAmGav (Gavin Perch)]

votre serveur de messagerie est configuré sur Digital Ocean.

Avez-vous un serveur de messagerie chez eux ?

[RGJ (Richard - Communiteq)]

C’est l’adresse IP du droplet qui exécute le récepteur de courriels.

nzarchitecture.net.nz. 2727 IN A 159.65.140.176

[IAmGav (Gavin Perch)]

Cela a changé au cours des 5 derniers mois

[RGJ (Richard - Communiteq)]

@Paul_King

La réponse par e-mail fonctionnait bien auparavant, mais il semble que cette fonctionnalité ait cessé de fonctionner autour du 29 septembre.

Je sais ce qui se passe. C’est encore cette maudite histoire de LetsEncrypt qui a cassé la moitié d’Internet de nombreuses choses le 30 septembre.

Self-hosted mail-receiver update following Let's Encrypt root certificate change

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…

Il suffit de reconstruire le conteneur Docker du récepteur de courrier.

[IAmGav (Gavin Perch)]

@RGJ

C’est encore ce truc @#(($* Let’s Encrypt qui a planté

Hahahaha, oui. J’avais oublié ça. MDR

[IAmGav (Gavin Perch)]

Tu dois suivre le sujet publié par @RGJ.

Cela devrait résoudre ton problème.

Self-hosted mail-receiver update following Let's Encrypt root certificate change

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…

[Paul_King]

@RGJ

Il suffit de reconstruire le conteneur Docker du récepteur de courriel.

Ah, d’accord. Cela semble prometteur !
Comment reconstruis-je le « récepteur de courriel Docker » ? Est-ce différent de la reconstruction du « gestionnaire Docker » qui se produit lors de la mise à jour du forum via le tableau de bord ?

Dois-je simplement suivre cela ? Comment mettre à jour manuellement Discourse et l’image Docker vers la dernière version ? - tutoriel / administrateurs - Discourse Meta

[IAmGav (Gavin Perch)]

Vous devez vous connecter à l’interface en ligne de commande de votre site.

Ce n’est pas via le tableau de bord d’administration du forum.

[Paul_King]

Bonjour, j’ai pu reconstruire le conteneur Docker du récepteur de courriel en suivant les instructions de ce lien : Livraison directe des courriels entrants pour les sites auto-hébergés - howto / sysadmin - Discourse Meta.

J’ai dû mettre à niveau et redimensionner mon droplet Digital Ocean pour y parvenir, car même après avoir supprimé toutes les sauvegardes, etc. stockées sur l’hôte, il n’y avait pas assez d’espace disque pour effectuer une reconstruction.

Après la reconstruction, j’ai pu envoyer ce message à staff@nzarchitecture.net.nz et le forum l’a cette fois reconnu.
Cependant, lorsque j’essaie de répondre par courriel à un sujet existant du forum dont j’ai été notifié, bien que les messages entrants soient maintenant reconnus, aucun n’apparaît sur le forum et tous génèrent des avertissements d’échec de livraison de courriel dans le journal.

Les messages entrants n’apparaissent pas dans le journal des courriels rebondis, mais ils figurent tous dans le journal des courriels rejetés avec l’avertissement [Email::Receiver::BadDestinationAddress] — y compris mon propre compte courriel d’administrateur, que j’espérais ne pas voir soudainement avoir une adresse de destination invalide.

[pfaffman (Jay Pfaffman)]

Avez-vous récemment reconstruit votre récepteur de courrier ?

[Paul_King]

Oui, je l’ai fait il y a environ une demi-heure, ce qui a donné le message ci-dessus. Je viens de procéder à une nouvelle reconstruction complète et (toucher du bois), tout semble fonctionner à nouveau.

[pfaffman (Jay Pfaffman)]

@Paul_King

Je viens de procéder à une nouvelle reconstruction complète, et (knock on wood) les choses semblent à nouveau fonctionner.

Il se peut que l’option forcer HTTPS n’ait pas été activée et que la reconstruction l’ait corrigée.

[Paul_King]

En fait, je venais de remarquer un avertissement à ce sujet dans le tableau de bord, et j’avais donc cliqué sur le lien pratique fourni vers le paramètre approprié et coché la case.

Je n’avais pas réalisé que le HTTPS forcé était obligatoire pour recevoir des e-mails entrants.

Il est possible que l’absence de HTTPS forcé ait également causé des problèmes avec la connexion via Facebook. J’ai récemment été informé par Facebook que mon site était en violation de leurs conditions d’utilisation et avait été suspendu. Il n’y avait aucune action requise dans mon panneau de contrôle des développeurs d’applications Facebook, j’ai donc fait appel. La réponse était qu’ils ne pouvaient pas vérifier le site en raison d’une erreur non spécifiée générée par l’URL de mon forum.

[Paul_King]

@Paul_King

Il est possible que l’absence de HTTPS imposé ait également causé des problèmes lors de l’utilisation de la connexion Facebook.

Il semble que cocher la case « forcer HTTPS » n’ait absolument rien changé pour la connexion Facebook. Le support technique de Facebook indique toujours que la page d’accueil du site génère un avertissement de sécurité « votre connexion n’est pas privée NET::ERR_CERT_COMMON_NAME_INVALID ».

Selon la page d’erreur, l’émetteur du certificat est « R3 » — ce qui, d’après une recherche Google, semble lié à Let’s Encrypt, les mêmes personnes dont l’expiration du certificat avait nécessité la reconstruction de l’installation Discourse.

Est-ce une coïncidence ? Cela suggère-t-il que la dernière version de Discourse (2.8.0 bêta 7) présente toujours un problème de certificat ? Ou s’agit-il d’un problème sans rapport, lié à l’hébergement ou à Digital Ocean ?

[Paul_King]

Mes propres recherches hasardeuses sur Google m’ont amené à tester mon URL via https://www.whynopadlock.com/, ce qui m’a conduit vers ce post d’un utilisateur de Let’s Encrypt :

Let’s Encrypt a récemment mis à jour son certificat intermédiaire de « Let’s Encrypt Authority X3 » vers « R3 ».

Si vous utilisez un client ACME conforme, il aurait automatiquement commencé à utiliser le nouvel intermédiaire lors de votre dernière renewal. Vous n’auriez dû remarquer aucune différence.

Dans votre cas, peut-être avez-vous codé en dur le certificat intermédiaire. Si c’est le cas, vous devrez utiliser le nouvel intermédiaire, que vous pouvez trouver sur Chains of Trust - Let's Encrypt : https://letsencrypt.org/certs/lets-encrypt-r3-cross-signed.pem

La version actuelle de Discourse code-t-elle peut-être incorrectement le certificat intermédiaire ?

Les certificats intermédiaires sont-ils désormais quelque chose que les administrateurs Discourse doivent gérer ? Et si oui, comment ?

Merci de me faire savoir si je suis hors sujet — je ne suis pas sûr qu’il s’agisse de la même problématique ou non.