Import_mbox.sh não funciona com e-mails do telefone Samsung enviados via servidor de lista

Um problema estranho surgiu em minha configuração de teste, onde estou copiando e-mails para o meu servidor Discourse e executando o import_mbox.sh para incorporar esses e-mails. Os e-mails originais são de uma lista de e-mails.

Descobri que, se as pessoas estiverem usando telefones Samsung e respondendo a um e-mail anterior da lista, se eu tentar importar esse e-mail resultante para o Discourse, ele não extrai o novo conteúdo, mas apenas exibe uma duplicata do e-mail original, mas rotulado como se a pessoa que respondeu o tivesse escrito.

Se eu copiar e colar o e-mail bruto que está causando problemas na caixa de Teste Avançado de E-mails, o mesmo problema está presente. Se eu truncar o e-mail e remover várias partes adicionadas pela Samsung, parece funcionar.

Não posso colocar cópias dos e-mails que desencadeiam isso aqui, pois são confidenciais. E-mails que não são importados têm seções como esta (e não há conteúdo legível por humanos - está tudo em codificação base64):

[cabeçalhos truncados aqui]
Content-Type: multipart/alternative;
	boundary="--_com.samsung.android.email_341310020171250"

----_com.samsung.android.email_341310020171250
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=UTF-8

VGhlIGxlZ2lzbGF0aW9uI[truncado]
[...]
[truncado]X19fX19fX19fX18NCg==
----_com.samsung.android.email_341310020171250
Content-Type: multipart/related;
	boundary="--_com.samsung.android.email_341310031317791"

Então você precisará modificar import_mbox.sh para truncar o e-mail e remover o lixo da Samsung.

Poderia ser um problema que poderia ser resolvido no core, pois essas mensagens provavelmente falham quando processadas por e-mail (mas eu não olho o código ultimamente, então não sei). Em qualquer caso, a solução mais rápida provavelmente será modificar o script de importação para essas mensagens.

Ou talvez alguém reconheça isso como um problema no core e o corrija.

1 curtida

Após investigar um pouco mais, parece que o aplicativo de e-mail da Samsung codifica uma parte de texto simples e uma parte HTML, cada uma codificada em base64. Descobri que, se eu adicionar uma linha em branco entre as duas codificações, o filtro de e-mail funciona corretamente. Pode ser que a Samsung não esteja adicionando uma linha em branco onde deveria, ou pode ser que o filtro de e-mail não esteja localizando corretamente a parte de texto simples/HTML e não perceba que, uma vez encontrada a parte HTML, ele sabe onde o cabeçalho termina e o conteúdo da mensagem começa.

Tentei copiar o e-mail original do Gmail (via ver original) e também exportar a mesma mensagem do Thunderbird, com os mesmos resultados.

E-mails gerados pela Samsung parecem ter isto no final dos cabeçalhos:

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[a mensagem de texto simples codificada em base64 vai aqui]

e isso termina com

[mais dados codificados em base64 aqui]19fDQo=
----_com.samsung.android.email_396413402758380
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8

PGh0b[codificação base64 novamente, desta vez codificando a versão HTML da mesma mensagem]

e isso termina com

[mais dados codificados em base64]NCg==
----_com.samsung.android.email_396413402758380--

Agora, se eu alterar a parte do meio adicionando uma linha em branco (após a parte “email_396413402758380”), tudo funciona perfeitamente!

[mais dados codificados em base64 aqui]19fDQo=
----_com.samsung.android.email_396413402758380

Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8

PGh0b[codificação base64 novamente, desta vez codificando a versão HTML da mesma mensagem]

Isso sugere um bug no importador?

Para mim, isso sugere um bug no serviço de e-mail da Samsung. Mas não sei, e não importa de quem é o bug.

No entanto, a correção mais fácil será adicionar um gsub no script de importação que adiciona a linha em branco que você descreve.

Provavelmente é mais fácil inserir uma linha antes de Content-Transfer-Encoding: base64

Espero que isso não quebre mais nada.

Mas Gerhard está escrevendo uma resposta melhor… agora mesmo

1 curtida

Bem, nesse caso, eu diria que é um bug na gem mail que usamos para analisar e-mails ou um bug no aplicativo Samsung. Após uma rápida olhada nos RFCs, eu diria que provavelmente é um bug no analisador.

Você poderia, por acaso, fornecer um exemplo completo de um e-mail problemático como esse? Talvez você pudesse pedir a um dos autores de seus e-mails confidenciais para lhe enviar um e-mail não confidencial?

2 curtidas

Tentei criar um e-mail decodificando o base64, alterando a redação e, em seguida, recodificando e encontrei algo mais interessante.

A remoção de um caractere de espaço no meio da mensagem original pode fazer com que a resposta escrita acima seja extraída corretamente.

Neste exemplo, no meio da mensagem HTML codificada em base64, se eu encontrar uma linha contendo um [espaço] antes de uma barra div e removê-la, então mude

21  20:17  (GMT+00:00) </div><div>To: LIST@LISTS

para

21  20:17  (GMT+00:00)</div><div>To: LIST@LISTS

através da remoção do caractere [espaço] antes da /div, em seguida, recodificar para base64 e colocá-lo de volta na caixa de teste de mensagem nas configurações de administrador, então o filtro funciona.

Posso postar um e-mail por mensagem direta se ajudar?

Aqui está um e-mail artificial que criei, o qual acredito demonstrar o problema. Se você olhar a parte HTML, ela contém uma resposta a uma mensagem anterior. O importador não parece conseguir ver onde a mensagem original começou.

From someone@gmail
Delivered-To: someone@gmail
Importance: Normal
MIME-Version: 1.0
Message-ID: <E1mt6gg-00H2OV-6N@relay01.mail.eu.clara.net>
Date: Fri, 3 Dec 2021 11:25:05 +0000
From: someone <someone@somewhere.net>
Subject: Re: Example e-mail
To: <LIST@LISTSERV>
In-Reply-To: <007301d7e834$c268a3e0$4739eba0$@sslmc.co.uk>
Precedence: list
Content-Type: multipart/alternative;
	boundary="--_com.samsung.android.email_7076959834053910"

----_com.samsung.android.email_7076959834053910
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=UTF-8

WWVzIGFuZCB3ZSBhcmUgZ2V0dGluZyBsb3RzIGluIEFCQyBhbmQgdXJnZW50IGNhcmUsIGFsb25n
IHdpdGggdmFjY2luYXRpb24gc2lkZSBlZmZlY3RzIGZyb20gZmx1ICsgYm9vc3Rlci4gQXBwYXJl
bnRseSBERUYxMTEgY2FuJ3QgZGVhbCB3aXRoIHRoaXMgc29ydCBvZiBxdWVyeS4gTG9va2luZyBn
b29kIGZvciBYbWFzIGFuZCBOWSB3ZWVrICAgIDIyMjIKClNhbQoKRHIgU2FtIFNtaXRoeSAKCgot
LS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tCkZyb206IFNvdXRoIFNvdXRocyBYWVog
PGVucXVpcnlAU1NYWVouQ08uVUs+CkRhdGU6IDAzLzEyLzIwMjEgMTA6NTkgKEdNVCswMDowMCkK
VG86IExJU1RTQExJU1RTRVJWLkFCQy5PUkcuVUsKU3ViamVjdDogZXZlcnl0aGluZyBsYW5kcyBi\nYWNrIGF0IG91ciBkb29yIQoKUHJhY3RpY2VzIHJlcG9ydGluZyB0byBnZXQgIDIgb3IgMyBxdWVy
aWVzL2RheSBmcm9tIHBhdGllbnRzIHJlZ2FyZGluZyBmaXZlcyB2YWNjaW5lIGlzc3VlcyB3aG8g
aGF2ZSBiZWVuIHJlZmVycmVkIHRvIHRoZWlyIEdQIGJ5IFhZWiAxMjMgb3IgdGhlIE5CUy4gIFRo
ZXNlIHF1ZXJpZXMgaW5jbHVkZSBzY2hlZHVsaW5nIGRvc2VzIGZvciBpbW11bm9zdXBwcmVzc2Vk
IHB0cyBhcyB3ZWxsIGFzIHBoYXJtYWNldXRpY2FsIHF1ZXN0aW9ucy4gIA==
----_com.samsung.android.email_7076959834053910
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXYgZGlyPSJh
dXRvIj5ZZXMgYW5kIHdlIGFyZSBnZXR0aW5nIGxvdHMgaW4gQUJDIGFuZCB1cmdlbnQgY2FyZSwg
YWxvbmcgd2l0aCB2YWNjaW5hdGlvbiBzaWRlIGVmZmVjdHMgZnJvbSBmbHUgKyBib29zdGVyLiBB
cHBhcmVudGx5IERFRjExMSBjYW4ndCBkZWFsIHdpdGggdGhpcyBzb3J0IG9mIHF1ZXJ5LiBMb29r
aW5nIGdvb2QgZm9yIFhtYXMgYW5kIE5ZIHdlZWsmbmJzcDsgJm5ic3A7IDIyMjI8L2Rpdj48ZGl2
IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5TYW08L2Rpdj48ZGl2IGRpcj0i
YXV0byI+PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSIgZGlyPSJhdXRvIj48
bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl
dD1VVEYtOCI+RHIgU2FtIFNtaXRoeSZuYnNwOzwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9k
aXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGFsaWduPSJsZWZ0IiBkaXI9ImF1dG8i
IHN0eWxlPSJmb250LXNpemU6MTAlO2NvbG9yOiMzMDAwMDAwIj48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFs
IG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206IFNvdXRoIFNvdXRocyBYWlombHQ7ZW5x
dWlyeUBTU1hZWouQ08uVUsmc2h0OyA8L2Rpdj48ZGl2PkRhdGU6IDAzLzEyLzIwMjEgIDEwOjU5
ICgR01UKzAwOjAwKSA8L2Rpdj48ZGl2PlRvOiBMSVNUU0BMSVNUU0VSVi5BQkMuT1JHLlVLIDwv
ZGl2PjxkaXY+U3ViamVjdDogZXZlcnl0aGluZyBsYW5kcyBiYWNrIGF0IG91ciBkb29yISA8L2Rp
dj48ZGl2Pjxicj48L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseSYmcXVvdDtBcmlhbCZxdW90Oyxx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPlByYWN0aWNlcyByZXBvcnRpbmcgdG8gZ2V0ICYubWJzcDsy
IG9yIDM virtual/queriesL2RheSBmcm9tIHBhdGllbnRzIHJlZ2FyZGluZyBmaXZlcyB2YWNjaW5l
IGlzc3VlcyB3aG8gaGF2ZSBiZWVuIHJlZmVycmVkIHRvIHRoZWlyIEdQIGJ5IFhZWiAxMjMgb3Iu
LiB0aGUgTkJTLiAmbmJzcDsgVGhlc2UgcXVlcmllcyBpbmNsdWRlIHNjaGVkdWxpbmcgZG9zZXMg
Zm9yIGltbXVub3N1cHByZXNzZWQgcHRzIGFzIHdlbGwgYXMgcGFybWFjZXV0aWNhbCBxdWVzdGlv
bnMuJm5ic3A7IDwvc3Bhbj48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4=
----_com.samsung.android.email_7076959834053910--

Este problema parece afetar mensagens de outros clientes de e-mail também, estou descobrindo agora. Não posso postar publicamente os e-mails que geram as falhas para que todos analisem, mas ficaria feliz em deixá-los ver privadamente.

Minha configuração atual é que instalei o Discourse em um servidor doméstico, e-mails para uma lista de e-mails de mailing list são enviados para mim (que vai para uma conta do Gmail). Se um filtro ‘Para:’ corresponder ao nome da mailing list, configurei o Gmail para encaminhar uma cópia do e-mail para mailinglist@mydiscoursedomain.org.uk. O Discourse tem uma categoria configurada para espelhar uma mailing list que procura por este e-mail.

O mesmo problema ocorre se eu usar o script import_mbox.sh também, tendo copiado manualmente os e-mails, então deve ser a parte do código que procura a nova parte da mensagem que está confusa.

Existe alguma maneira de fazer o Discourse percorrer todos os e-mails importados armazenados anteriormente e tentar reformulá-los usando a parte de texto simples dos e-mails originais, caso isso seja uma solução temporária para o problema acima? Antes da importação, estava configurado para usar a parte HTML. Ao dar uma olhada usando ‘rails c’, posso ver que cada postagem parece ter o texto completo das mensagens recebidas armazenado (incluindo cabeçalhos de e-mail). Tentei executar o ‘rake posts:rebuild’ após desativar a opção HTML e, enquanto ele avança lentamente por todas as mensagens, não tenho certeza se algo mudou, por exemplo, tentei ativar e desativar a opção mostrar conteúdo recortado também, mas a caixinha com três pontos ainda parece estar lá nas postagens após o término do rake.