Selbst gehostetes Reply by Email funktioniert nach dem letzten Update nicht mehr

Unterstützung
1

Mein Forum reagiert nicht mehr auf Antworten, die per E-Mail gesendet werden.

Die Funktion „Antwort per E-Mail" hat zuvor gut funktioniert, scheint jedoch seit dem 29. September nicht mehr zu arbeiten.

Ich habe keine eindeutigen Beweise für diesen Zeitpunkt, da das Forum nicht sehr aktiv ist, aber es funktioniert definitiv nicht mehr, und die Forum-Protokolle zeigen keine empfangenen Nachrichten nach dem 29. September.

Das Protokoll abgelehnter E-Mails enthält ebenfalls den letzten Eintrag vom 29. September. Alle abgelehnten Nachrichten stammen von Einweg-Adressen und enthalten Inhalte, die wie Spam aussehen – dies scheint also wie vorgesehen zu funktionieren.

Das Protokoll für zurückgeworfene E-Mails ist leer bzw. zeigt „keine Protokolle gefunden".

Nachrichten, die vom Forum generiert werden und durch Aktivitäten angemeldeter Benutzer ausgelöst werden, werden weiterhin versendet (ich erhalte sie zumindest), obwohl die Aktivitätslevel aufgrund des oben Genannten noch niedriger als sonst sind. Fast alle aktiven Benutzer bevorzugen E-Mail gegenüber der browserbasierten Interaktion.

Getestete Antwort-E-Mails auf Forum-Post-E-Mail-Benachrichtigungen, die entweder von meiner eigenen, bei Microsoft gehosteten E-Mail-Adresse oder von meiner Gmail-Adresse gesendet wurden, erhalten keine Rücksendewarnungen. Sie verschwinden einfach spurlos. Im E-Mail-Protokoll des Forums erscheint nichts.

Das Fehlerprotokoll des Forums zeigt einige Warnungen (gelbes Ausrufezeichen-Symbol) für den 29. September: „Email can not be processed: Email::Receiver::BadDestinationAddress Received…", die harmlos wirken bzw. keinen Unterschied zu früheren ähnlichen protokollierten Ereignissen aufweisen. Ich gehe davon aus, dass es sich lediglich um abgelehnten Spam handelt.

Am 1. Oktober wurde ein tatsächlicher Fehler protokolliert:

Nachricht

ActionDispatch::Http::MimeNegotiation::InvalidType (“%{#context[‘com.opensymphony.xwork2.dispatcher.httpservletresponse’].addheader(‘cbu0psig’” ist kein gültiger MIME-Typ)
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’

Rückverfolgung

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

Ich habe keine Ahnung, ob dies relevant ist, und seitdem sind keine weiteren Fehler oder schwerwiegenden Fehler (gekennzeichnet durch rote Kreuz-Symbole in heller oder dunkler Farbe) im Protokoll aufgetreten.

Weder meine E-Mail-Adressen erscheinen auf www.mail-tester.com als spamverdächtig oder anderweitig auf einer schwarzen Liste, noch gab es Probleme bei der Kommunikation mit Menschen von diesen Adressen.

Das Forum nutzt Mailgun, wobei ich davon ausgehe, dass dies nur für den Versand von Massen-E-Mails dient und dass Probleme mit dem Mailgun-Konto oder dem API-Schlüssel keine Auswirkungen auf eingehende Nachrichten haben sollten? Übrigens gibt es beim Einloggen in mein Mailgun-Konto keine offensichtlichen Probleme oder Fehlermeldungen mit Mailgun.

Ich gehe davon aus, dass der Mailgun-API-Schlüssel in Ordnung sein muss, wenn das Forum E-Mails weiterhin ordnungsgemäß versendet.

Seit die Funktion „Antwort per E-Mail" noch funktionierte, wurden keine Forum-Einstellungen geändert, und ich sehe, dass das Kontrollkästchen für die Einstellung „Antwort per E-Mail" immer noch aktiviert ist.

Das Forum wird auf Digital Ocean gehostet. Keine DNS-Einstellungen für die Domain wurden in den Digital Ocean-Einstellungen geändert, und die Forum-MX-Einträge scheinen in Ordnung/ungeändert zu sein.

Das Forum wurde seit Beginn des Problems auf Version 2.8.0 Beta 7 aktualisiert (wahrscheinlich wurde dabei ein Neuaufbau durchgeführt), aber es gab keine Verbesserung.

Was übersehe ich hier?
Was ist wahrscheinlich schiefgelaufen?
Wie bekomme ich die Funktion „Antwort per E-Mail" wieder zum Laufen?

1 „Gefällt mir“
2

Dieser Fehler scheint nicht damit zusammenzuhängen.

Im Allgemeinen ist es einfacher, „E-Mail-Eingang" zu testen als „Antwort per E-Mail". Aktiviere die Einstellungen für „Manuelles Polling" und „E-Mail-Eingang", füge eine E-Mail-Adresse zur Kategorie „Mitarbeiter" hinzu und prüfe, ob du eine E-Mail von derselben Adresse senden kannst, die du auch für dein Forum-Admin-Benutzerkonto verwendest.

Überprüfe dann unter Admin - E-Mail - Zurückgewiesen / Empfangen / Abgelehnt, was los ist.

Ist deine „Antwort-E-Mail-Adresse" korrekt konfiguriert?

5 „Gefällt mir“
3

Hallo, danke, Richard.

Ich kann bestätigen, dass die Einstellungen „Manuelles Polling aktiviert" und „E-Mail-Eingang" weiterhin aktiviert sind.

Ich habe meine Gmail-Adresse als benutzerdefinierte Adresse zur Kategorie „Mitarbeiter" hinzugefügt, aber ich sehe keine Möglichkeit, über das Forum Nachrichten an das Team zu senden? Alle „Kontaktieren Sie uns"-Links sind in den Forumseinstellungen als mailto-Links eingerichtet, die einfach zu meiner persönlichen Alltags-E-Mail-Adresse führen. Wenn man auf einen dieser Links klickt, öffnet sich meine E-Mail-Anwendung, die bereits mit meiner persönlichen direkten E-Mail-Adresse vorausgefüllt ist. Das bedeutet, dass das Forum die Nachricht niemals erhalten würde.

4

Nein, du solltest in den Kategorieeinstellungen etwas wie staff@nzarchitecture.net.nz einrichten und dann über dein Gmail eine Nachricht an diese Adresse senden.

5

Ah, ok.

Ich habe genau das versucht, aber in keinem der Protokolle für abgelehnte, empfangene oder zurückgewiesene Nachrichten ist etwas erschienen.

6

Ihr Mailserver ist auf Digital Ocean eingerichtet.

image
image745×151 10.5 KB

Haben Sie einen Mailserver bei ihnen?

7

Das ist die IP-Adresse des Droplets, auf dem der Mail-Empfänger läuft.

nzarchitecture.net.nz. 2727 IN A 159.65.140.176

8

Das hat sich in den letzten 5 Monaten geändert.

image
image1123×176 3.28 KB

9

Ich weiß, was los ist. Es ist wieder dieses @#(($* LetsEncrypt-Ding, das am 30. September die Hälfte des Internets viele Dinge lahmgelegt hat.

Rebuilde einfach den Mail-Receiver-Docker.

6 „Gefällt mir“
10

hahahahaha, ja. Das hab ich vergessen. LOL

3 „Gefällt mir“
12

Du musst dem Thema folgen, das @RGJ gepostet hat.

Das sollte dein Problem beheben.

4 „Gefällt mir“
13

Ah, ok. Das klingt vielversprechend!
Wie rekonstruiere ich den „Mail-Receiver-Docker"? Ist das anders als das Rebuilden des „Docker-Managers", das beim Aktualisieren des Forums über das Dashboard erfolgt?

Soll ich einfach diesem Link folgen? Wie aktualisiere ich Discourse und das Docker-Image manuell auf die neueste Version? - Anleitung / Administratoren - Discourse Meta

14

Du musst dich auf der Befehlszeilenseite deiner Website anmelden.

Das erfolgt nicht über das Forum-Admin-Dashboard.

15

Hallo, ich konnte den Mail-Empfänger-Docker-Container mithilfe der Anweisungen unter diesem Link neu aufsetzen: Direkte Zustellung eingehender E-Mails für selbst gehostete Sites – Howto / Systemadministrator – Discourse Meta.

Dafür musste ich meine DigitalOcean-Droplet-Instanz aufrüsten und vergrößern, da selbst nach dem Löschen aller auf dem Host gespeicherten Backups usw. nicht genügend Festplattenspeicher für einen Neuaufbau vorhanden war.

Nach dem Neuaufbau konnte ich diese Nachricht an staff@nzarchitecture.net.nz senden – und das Forum hat sie dieses Mal bestätigt.
Wenn ich jedoch per E-Mail auf ein bestehendes Thema des Forums antworte, zu dem ich eine Benachrichtigung erhalten habe, werden die eingehenden Nachrichten zwar bestätigt, erscheinen aber nicht im Forum. Stattdessen werden im E-Mail-Protokoll für alle Nachrichten Warnungen zum „Mail Delivery Failure" angezeigt.

Die eingehenden Nachrichten erscheinen nicht im Protokoll für abgelehnte E-Mails, tauchen jedoch alle im Protokoll für abgelehnte E-Mails mit der Warnung [Email::Receiver::BadDestinationAddress] auf – einschließlich meines eigenen Administratorkontos, das ich nicht plötzlich als ungültige Zieladresse betrachten würde.

16

Haben Sie Ihren Mail-Empfang in letzter Zeit neu aufgebaut?

3 „Gefällt mir“
17

Ja – das habe ich vor etwa einer halben Stunde getan, was zu dem Beitrag oben geführt hat. Ich habe gerade erneut einen vollständigen Neuaufbau durchgeführt, und (fingers crossed) scheint alles wieder zu funktionieren.

1 „Gefällt mir“
18

Möglicherweise war „Force HTTPS" nicht aktiviert, und die Neuinstallation hat das Problem behoben.

1 „Gefällt mir“
19

Tatsächlich hatte ich gerade eine Warnung genau dazu im Dashboard gesehen und daher auf den praktischen, bereitgestellten Link zur entsprechenden Einstellung geklickt und das Kästchen angehakt.

Mir war nicht bewusst, dass die Erzwingung von HTTPS für den Empfang eingehender E-Mails obligatorisch ist.

Es ist möglich, dass das Fehlen einer erzwungenen HTTPS-Verbindung auch Probleme beim Verwenden der Facebook-Login-Funktion verursacht hat. Facebook hat mich kürzlich darüber informiert, dass meine Website gegen deren Nutzungsbedingungen verstoßen und gesperrt wurde. Im Entwickler-Steuerungsbereich meiner Facebook-Apps gab es keine Handlungsaufforderungen, daher habe ich Einspruch eingelegt. Die Antwort lautete, dass sie die Website aufgrund eines nicht näher bezeichneten Fehlers, der von meiner Forum-URL generiert wurde, nicht verifizieren konnten.

1 „Gefällt mir“
20

Das Ankreuzen des Feldes „HTTPS erzwingen" hat beim Facebook-Login anscheinend überhaupt nicht geholfen. Der Facebook-Support gibt weiterhin an, dass die Startseite der Website bei ihnen eine Sicherheitswarnung mit dem Hinweis „Ihre Verbindung ist nicht privat" und dem Fehlercode „NET::ERR_CERT_COMMON_NAME_INVALID" auslöst.

Laut der Fehlerseite lautet der Aussteller des Zertifikats „R3". Eine Google-Suche deutet darauf hin, dass dies mit Let’s Encrypt zusammenhängt – derselben Organisation, deren abgelaufenes Zertifikat die Notwendigkeit ausgelöst hat, die Discourse-Installation neu aufzubauen.

Ist das ein Zufall? Legt dies nahe, dass die neueste Discourse-Version (2.8.0 beta 7) immer noch ein Zertifikatsproblem hat? Oder handelt es sich um ein unabhängiges Problem im Zusammenhang mit dem Hosting bei Digital Ocean?

21

Meine eigene etwas holprige Google-Recherche hat mich dazu gebracht, meine URL mit https://www.whynopadlock.com/ zu testen. Die Ergebnisse haben mich zu diesem Beitrag eines Let’s Encrypt-Nutzers geführt:

Let’s Encrypt hat sein Zwischenzertifikat kürzlich von „Let’s Encrypt Authority X3" auf „R3" aktualisiert.

Wenn Sie einen konformen ACME-Client verwenden, hätte dieser beim letzten Verlängerungsvorgang automatisch das neue Zwischenzertifikat übernommen. Sie hätten keinen Unterschied bemerken sollen.

In Ihrem Fall haben Sie möglicherweise das Zwischenzertifikat fest codiert. Falls ja, müssen Sie das neue Zwischenzertifikat verwenden, das Sie unter Chains of Trust - Let's Encrypt finden: https://letsencrypt.org/certs/lets-encrypt-r3-cross-signed.pem

Verwendet die aktuelle Version von Discourse das Zwischenzertifikat vielleicht fälschlicherweise „fest codiert"?

Sind „Zwischenzertifikate" nun etwas, das von Discourse-Administratoren verwaltet werden muss? Und wenn ja, wie?

Bitte lassen Sie mich wissen, ob ich jetzt vom Thema abkomme – ich bin mir nicht sicher, ob es sich um denselben Fehler handelt oder nicht.