Reply by Email self-hosted smesso di funzionare dopo l'ultimo aggiornamento

Supporto
1

Il mio forum non risponde più alle risposte inviate via email.

La risposta via email funzionava correttamente in precedenza, ma sembra che questa funzionalità abbia smesso di funzionare intorno al 29 settembre.

Non ho prove definitive per questa tempistica, dato che il forum non è molto attivo, ma di certo ora non funziona più e i log del forum non mostrano messaggi ricevuti dopo il 29 settembre.

Anche il registro delle email rifiutate ha l’ultima voce in data 29 settembre. Tutti i messaggi rifiutati provengono da indirizzi usa e getta e contengono contenuti che sembrano spam, quindi sembra che questa parte funzioni come dovrebbe.

Il registro delle email rimbalzate è vuoto o mostra “nessun log trovato”.

I messaggi continuano a essere inviati dal forum in seguito alle attività degli utenti registrati (almeno io li ricevo), sebbene i livelli di attività siano ancora più bassi del normale a causa di quanto sopra. Quasi tutti gli utenti attivi preferiscono l’email rispetto all’interazione tramite browser.

Le risposte di test inviate via email alle notifiche dei post del forum, inviate sia dal mio indirizzo email ospitato su Microsoft che dal mio account Gmail, non generano avvisi di rimbalzo. Semplicemente scompaiono senza lasciare traccia. Non compare nulla nel registro email del forum.

Il registro degli errori del forum mostra un paio di avvisi (icona di punto esclamativo giallo) per il 29 settembre: “Email can not be processed: Email::Receiver::BadDestinationAddress Received…”, che sembrano innocui e non diversi da eventi simili registrati in precedenza. Presumo si tratti di spam rifiutato.

Il 1° ottobre è stato registrato un errore effettivo:

Messaggio

ActionDispatch::Http::MimeNegotiation::InvalidType (“%{#context[‘com.opensymphony.xwork2.dispatcher.httpservletresponse’].addheader(‘cbu0psig’” non è un tipo MIME valido)
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

Non so se questo sia rilevante; inoltre, da allora non sono apparsi altri errori o errori fatali (indicati da icone di croce rossa chiara o scura) nel log.

Né il mio indirizzo email né quello del forum sembrano essere spam o inseriti in blacklist quando testati su www.mail-tester.com, e non ho riscontrato problemi nella comunicazione con persone reali da questi indirizzi.

Il forum utilizza Mailgun, anche se presumo che sia usato solo per l’invio di email in massa, e che eventuali problemi con l’account Mailgun o la chiave API non dovrebbero influire sui messaggi in arrivo? A proposito, non ho trovato problemi evidenti o messaggi di errore relativi a Mailgun quando ho effettuato l’accesso al mio account Mailgun.

Presumo che la chiave API di Mailgun sia corretta se il forum riesce ancora a inviare email correttamente.

Nessuna impostazione del forum è stata modificata da quando la risposta via email funzionava, e vedo che la casella di controllo “rispondi via email” è ancora spuntata.

Il forum è ospitato su Digital Ocean. Nessuna impostazione DNS per il dominio è stata modificata nelle impostazioni di Digital Ocean, e i record MX del forum sembrano corretti e invariati.

Il forum è stato aggiornato alla versione 2.8.0 beta 7 da quando è iniziato il problema (presumibilmente con un processo di ricostruzione), ma senza alcun miglioramento.

Cosa sto trascurando?
Cosa è andato probabilmente storto?
Come posso far funzionare di nuovo la risposta via email?

2

Quell’errore sembra non essere correlato.

In generale, è più semplice testare l’“invio email” rispetto al test della risposta tramite email. Abilita le impostazioni manual polling enabled e email in, aggiungi un indirizzo email alla categoria staff e verifica se riesci a inviare email a quell’indirizzo utilizzando lo stesso indirizzo email associato al tuo account amministratore del forum.

Quindi controlla Amministratore - Email - Rimbalzate / Ricevute / Rifiutate per vedere cosa sta succedendo.

L’indirizzo email per risposta tramite email è configurato correttamente?

3

Ciao, grazie Richard

Posso confermare che le impostazioni ‘polling manuale abilitato’ e ‘email in’ sono ancora attive.

Ho aggiunto il mio indirizzo Gmail come indirizzo personalizzato alla categoria staff, ma non riesco a trovare un modo per inviare messaggi allo staff tramite il forum? Tutti i link ‘contattaci’ sono configurati nelle impostazioni del forum come link mailto che reindirizzano semplicemente al mio indirizzo email personale quotidiano: cliccando su uno di questi si apre la mia applicazione di posta, già compilata con il mio indirizzo email diretto personale, il che significa che il forum non riceverà mai il messaggio.

4

No, dovresti configurare qualcosa come staff@nzarchitecture.net.nz nelle impostazioni della categoria, quindi utilizzare la tua Gmail per inviare un messaggio a quell’indirizzo.

5

Ah, ok.

Ho provato esattamente questo, ma non è apparso nulla in nessuno dei registri di rimbalzo/ricezione/rifiuto

6

Il tuo server di posta è impostato su Digital Ocean.

image
image745×151 10.5 KB

Hai un server di posta con loro?

7

Questo è l’IP del droplet, che esegue il mail-receiver.

nzarchitecture.net.nz. 2727 IN A 159.65.140.176

8

È cambiato negli ultimi 5 mesi

image
image1123×176 3.28 KB

9

So cosa sta succedendo. È di nuovo quella maledetta faccenda di @#(($* LetsEncrypt che ha rotto metà di Internet molte cose il 30 settembre.

Basta ricreare il Docker del ricevitore di posta.

10

hahahahaha, sì. Me ne ero dimenticato. LOL

12

Devi seguire l’argomento pubblicato da @RGJ.

Questo dovrebbe risolvere il tuo problema.

13

Ah, ok. Sembra promettente!
Come ricreo il “ricevitore di posta Docker”? È diverso dal ricreare il “gestore Docker” che avviene quando si aggiorna il forum tramite la dashboard?

Devo solo seguire questa guida? Come aggiornare manualmente Discourse e l’immagine Docker all’ultima versione? - howto / amministratori - Discourse Meta

14

Devi accedere alla riga di comando del tuo sito.

Non è possibile farlo dal pannello di amministrazione del forum.

15

Ciao, sono riuscito a ricostruire il container Docker per la ricezione delle email seguendo le istruzioni presenti in questo link Consegna diretta delle email in arrivo per siti self-hosted - howto / sysadmin - Discourse Meta

Ho dovuto aggiornare e ridimensionare il mio droplet su Digital Ocean per farlo, poiché anche dopo aver eliminato tutti i backup e altri dati archiviati sull’host, non c’era abbastanza spazio su disco per eseguire la ricostruzione.

Dopo la ricostruzione, sono riuscito a inviare quel messaggio a staff@nzarchitecture.net.nz e il forum questa volta l’ha riconosciuto.
Tuttavia, quando provo a rispondere via email a un argomento esistente del forum di cui ho ricevuto una notifica, sebbene i messaggi in arrivo vengano ora riconosciuti, nessuno di essi appare sul forum e tutti generano avvisi di “Fallimento della consegna della posta” nel registro delle email.

I messaggi in arrivo non appaiono nel registro delle email rimbalzate, ma compaiono tutti nel registro delle email rifiutate con l’avviso [Email::Receiver::BadDestinationAddress], incluso il mio account email amministratore, che speravo non avesse improvvisamente un indirizzo di destinazione errato.

16

Hai ricostruito di recente il tuo ricevitore di posta?

17

Sì, l’ho fatto circa mezz’ora fa, il che ha portato al post sopra.
Ho appena eseguito un’altra completa ricompilazione e (tocca ferro) sembra che tutto stia funzionando di nuovo.

18

Potrebbe essere che l’opzione “force https” non fosse impostata e il rebuild l’abbia risolta.

19

In realtà, avevo appena notato un avviso proprio su questo nella dashboard e quindi ho cliccato sul link utile fornito per la relativa impostazione e ho spuntato la casella.

Non avevo realizzato che l’uso forzato di HTTPS fosse obbligatorio per ricevere email in arrivo.

È possibile anche che la mancanza di HTTPS forzato abbia causato problemi nell’uso del login con Facebook: di recente sono stato informato da Facebook che il mio sito era in violazione dei loro termini di servizio ed è stato sospeso. Non c’erano azioni da intraprendere nel pannello di controllo degli sviluppatori delle mie app su Facebook, quindi ho fatto ricorso e la risposta è stata che non potevano verificare il sito a causa di un errore non specificato generato dall’URL del mio forum.

20

Sembra che spuntare la casella ‘force https’ non abbia affatto risolto il problema dell’accesso con Facebook. Il supporto tecnico di Facebook continua a segnalare che la pagina di atterraggio del sito genera un avviso di sicurezza ‘la tua connessione non è privata
NET::ERR_CERT_COMMON_NAME_INVALID’.

Secondo la pagina dell’errore, l’emittente del certificato è indicato come ‘R3’, il che, da una ricerca su Google, sembra essere correlato a Let’s Encrypt, gli stessi responsabili il cui certificato scaduto ha reso necessario ricostruire l’installazione di Discourse.

È una coincidenza? Questo suggerisce che l’ultima versione di Discourse (2.8.0 beta 7) abbia ancora un problema con il certificato, o si tratta di un problema non correlato legato all’hosting/Digital Ocean?

21

La mia ricerca goffa su Google mi ha portato a testare il mio URL utilizzando https://www.whynopadlock.com/, i cui risultati mi hanno condotto a questo post di un utente di Let’s Encrypt

Let’s Encrypt ha aggiornato di recente il proprio certificato intermedio da “Let’s Encrypt Authority X3” a “R3”.

Se utilizzi un client ACME ben configurato, questo avrebbe iniziato automaticamente a utilizzare il nuovo certificato intermedio al momento dell’ultimo rinnovo. Non avresti dovuto notare alcuna differenza.

Nel tuo caso, forse stai codificando manualmente il certificato intermedio. Se è così, dovrai utilizzare il nuovo certificato intermedio, che puoi trovare su https://letsencrypt.org/certificates: https://letsencrypt.org/certs/lets-encrypt-r3-cross-signed.pem

La versione attuale di Discourse sta forse codificando erroneamente il certificato intermedio?

I “certificati intermedi” sono ora qualcosa che gli amministratori di Discourse devono gestire? E in caso affermativo, come?

Fammi sapere se sto uscendo dall’argomento: non sono sicuro se si tratti della stessa problematica o meno.