È emerso uno strano problema nella mia configurazione di test in cui sto copiando le e-mail sul mio server Discourse ed eseguendo import_mbox.sh per incorporare tali e-mail. Le e-mail originali provengono da una mailing list listserv.
Ho scoperto che se le persone utilizzano telefoni Samsung e rispondono a una precedente e-mail listserv, se tento di importare l’e-mail risultante in Discourse, non estrae il nuovo contenuto ma presenta solo un duplicato dell’e-mail originale, etichettato come se fosse stato scritto dalla persona che ha risposto.
Se copio/incollo l’e-mail raw problematica nella casella Test Avanzato di Emails, si presenta lo stesso problema. Se tronco l’e-mail e rimuovo diverse parti aggiunte da Samsung, sembra funzionare.
Non posso inserire copie delle e-mail che attivano questo problema qui poiché sono confidenziali. Le e-mail che non vengono importate contengono sezioni come questa (e non c’è contenuto leggibile dall’uomo, è tutto in codifica base64):
Quindi dovrai modificare import_mbox.sh per troncare l’email e rimuovere le sciocchezze di Samsung.
Potrebbe essere un problema che potrebbe essere risolto nel core, poiché quei messaggi probabilmente falliscono quando vengono elaborati inviandoli via email (ma non ho guardato il codice di recente, quindi non lo so). In ogni caso, la soluzione più rapida sarà probabilmente quella di modificare lo script di importazione per quei messaggi.
O forse qualcuno riconoscerà questo come un problema nel core e lo risolverà.
Dopo aver approfondito un po’, sembra che l’app di posta elettronica Samsung codifichi una parte di testo normale e una parte HTML, ognuna codificata in base64. Ho scoperto che se aggiungo una riga vuota tra le due codifiche, il filtro e-mail funziona correttamente. Potrebbe essere che Samsung non aggiunga una riga vuota dove dovrebbe, o potrebbe essere che il filtro e-mail non stia individuando correttamente la parte di testo normale/HTML e non si renda conto che, una volta trovata la parte HTML, sa dove finisce l’intestazione di quest’ultima e inizia il contenuto del messaggio.
Ho provato a copiare l’e-mail originale da Gmail (tramite visualizza originale) e anche a esportare lo stesso messaggio da Thunderbird, con gli stessi risultati.
Le e-mail generate da Samsung sembrano avere questo in fondo alle intestazioni:
Content-Type: multipart/alternative;
boundary="--_com.samsung.android.email_396413402758380"
----_com.samsung.android.email_396413402758380
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=UTF-8
WWVz[qui va il messaggio di testo normale codificato in base64]
e questo termina con
[altri dati codificati in base64 qui]19fDQo=
----_com.samsung.android.email_396413402758380
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8
PGh0b[codifica base64 di nuovo, questa volta codifica la versione HTML dello stesso messaggio]
e questo termina con
[altri dati codificati in base64]NCg==
----_com.samsung.android.email_396413402758380--
Ora, se modifico la parte centrale aggiungendo una riga vuota (dopo la parte “email_396413402758380”), tutto funziona perfettamente!
[altri dati codificati in base64 qui]19fDQo=
----_com.samsung.android.email_396413402758380
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8
PGh0b[codifica base64 di nuovo, questa volta codifica la versione HTML dello stesso messaggio]
Beh, in tal caso direi che si tratta di un bug nella gem mail che utilizziamo per analizzare le email o di un bug nell’app Samsung. Dopo una rapida occhiata alle RFC, direi che si tratta probabilmente di un bug nel parser.
Potresti per caso fornire un esempio completo di un’email così problematica? Magari potresti chiedere a uno degli autori delle tue email riservate di inviarti un’email non riservata?
Ho provato a ideare un’e-mail decodificando il base64, modificando le parole, quindi ricodificando e ho trovato qualcos’altro di interessante.
La rimozione di uno spazio a metà del messaggio originale può far estrarre correttamente la risposta che è stata scritta sopra.
In questo esempio, nel mezzo del messaggio HTML codificato in base64, se trovo una riga contenente uno [spazio] prima di uno slash div e la rimuovo, quindi modifico
21 20:17 (GMT+00:00) </div><div>To: LIST@LISTS
in
21 20:17 (GMT+00:00)</div><div>To: LIST@LISTS
attraverso la rimozione dello [spazio] prima del /div, quindi ricodifico in base64 e lo reinserisco nella casella di test del messaggio nelle impostazioni di amministrazione, quindi il filtro funziona.
Potrei inviare un’e-mail tramite messaggio diretto se può essere d’aiuto?
Ecco un’e-mail contorta che ho creato e che penso dimostri il problema. Se guardi la parte HTML, c’è una risposta a un messaggio precedente. L’importatore non sembra essere in grado di vedere dove è iniziato il messaggio originale.
Sembra che questo problema influenzi anche i messaggi provenienti da altri client di posta. Sto scoprendo ora. Non posso pubblicare le e-mail che generano gli errori affinché tutti le esaminino, ma sarei felice di farle vedere a qualcuno in privato.
La mia attuale configurazione prevede che io abbia installato Discourse su un server domestico, le e-mail a una mailing list listserv mi vengono inviate (che finiscono su un account Gmail). Se un filtro ‘A:’ corrisponde al nome della mailing list, ho impostato Gmail per inoltrare una copia dell’e-mail a mailinglist@mydiscoursedomain.org.uk. Discourse ha una categoria impostata per rispecchiare una mailing list che cerca questa e-mail.
Lo stesso problema si presenta anche se utilizzo lo script import_mbox.sh avendo copiato manualmente le e-mail, quindi deve essere la parte del codice che cerca la nuova parte del messaggio a confondersi.
C’è un modo per far sì che Discourse elabori rapidamente tutte le e-mail importate precedentemente memorizzate e provi a riformattarle utilizzando la parte di testo normale delle e-mail originali nel caso in cui questa sia una soluzione temporanea al problema sopra menzionato? Prima dell’importazione era impostato per utilizzare la parte HTML. Dando una rapida occhiata usando ‘rails c’ posso vedere che ogni post sembra avere memorizzato il testo completo dei messaggi in arrivo (incluse le intestazioni delle e-mail). Ho provato a eseguire ‘rake posts:rebuild’ dopo aver disattivato l’opzione HTML e mentre elabora lentamente tutti i messaggi non sono sicuro che qualcosa sia cambiato, ad esempio ho provato ad attivare e disattivare anche l’opzione mostra contenuto troncato ma la piccola casella con tre puntini sembra essere ancora presente sui post dopo che il rake è terminato.